Introduction: What is WebSeal?
WebSEAL is a high performance, multi-threaded Web server that applies fine-grained security policy to the Tivoli Access Manager protected Web object space. WebSEAL can provide single sign-on solutions and incorporate back-end Web application server resources into its security policy.
WebSEAL normally acts as a reverse Web proxy by receiving HTTP/HTTPS requests from a Web browser and delivering content from its own Web server or from junctioned back-end Web application servers. Requests passing through WebSEAL are evaluated by the Tivoli Access Manager authorization service to determine whether the user is authorized to access the requested resource.
In simple terms, WebSeal intercepts all HTTP(S) requests from a browser and insures that protected web pages validate a user's right to access them before allowing the user to proceed. Once authenticated to WebSeal, all back-end resources (WebSphere, Portal, others) are authenticated in an SSO fashion so that the user only has to log in once.
Implications of Using WebSeal for Portal:
WebSeal has three important characteristics that affect how you install and implement Portal.
1) WebSeal must decompress (gunzip) all content from the Portal servers in order to rewrite URLs. Since hyperlinks in the content may refer to the Portal (or other WebSeal protected resources) and since WebSeal refers to these resources with different URLs than a browser would use, WebSeal has to insure that content uses the correct URL.
In order to rewrite the URLs in the content, the content cannot be compressed. So, compressing content in either the Portal or the web server (e.g. IHS or Apache) is a waste because WebSeal must decompress the content for the URL rewrite.
2a) WebSeal inserts an authorization header on all HTTP(S) requests in route to IHS and Portal. However, IHS's reverse proxy cache (mod_cache, mod_disk_cache, mod_mem_cache) will NOT serve any content if an authorization header is present in the request. Note that WebSeal does not insert this header if using LTPA junctions.
2b) WebSeal's proxy caching will NOT cache and responses for which there was a URL parameter (a "?" parameter) in the request. Portal makes heavy use of this pattern in it's "contenthandler" requests. Therefore, WebSeal is not appropriate as a proxy cache for Portal even though Portal requires one.
Recommendations for Portal When Using WebSeal:
1) Do not gzip content in either IHS (Apache) or Portal.
For IHS, this means no mod_deflate in httpd.conf.
For Portal, this means do not compress (my)contentHandler responses like ra:collections (which is enabled by default). To disable compression of (my)contentHandler responses in Portal do the following:
a. In the WAS admin console navigate to "Resources -> Resource Environment Providers -> WP_ConfigService -> Custom properties"
b. Add a new property:
c. Save the new configuration and restart the server
2) Insure that WebSeal is compressing all content (Encoding: gzip in the response header) to the browser.
3) Pick an appropriate point to proxy cache static resources based on the WebSeal junction type.