Trust Associations
Trust Association enables the integration of IBM WAS security and third-party security servers. More specifically, a reverse proxy server, such as Tivoli Access Manager - WebSEAL, can act as a front-end authentication server while WAS applies its own authorization policy onto the resulting credentials passed by the proxy server.
The reverse proxy server passes the HTTP request to the WAS that includes the credentials of the authenticated user. WAS then uses these credentials to authorize the request.
Trust association model
The idea that WAS can support trust association implies that WAS application security recognizes and processes HTTP requests received from a reverse proxy server. WAS and the proxy server engage in a contract in which WAS gives its full trust to the proxy server and the proxy server applies its authentication policies on every Web request that is dispatched to WAS. This trust is validated by the interceptors that reside in WAS environment for every request received. The method of validation is agreed upon by the proxy server and the interceptor.
Running in trust association mode does not prohibit WAS from accepting requests that did not pass through the proxy server. In this case, no interceptor is needed for validating trust. It is possible, however, to configure WAS to strictly require that all HTTP requests go through a reverse proxy server. In this case, all requests that do not come from a proxy server are immediately denied by WAS.
The integration of WebSEAL and WAS security is achieved by placing the WebSEAL server at the front-end as a reverse proxy server. From a WebSEAL management perspective, a junction is created with WebSEAL on one end, and WAS Web server on the other end. A junction is a logical connection created to establish a path from the WebSEAL server to another server.
In this setup, a request for Web resources stored in a protected domain of WAS is submitted to the WebSEAL server where it is authenticated against the WebSEAL security realm. If the requesting user has access to the junction, the request is transmitted to the WAS HTTP server through the junction, and then to the appserver.
Meanwhile, the WAS validates every request that comes through the junction to ensure that the source is a trusted party. This process is referenced as validating the trust and it is performed by a WebSEAL product-designated interceptor. If the validation is successful, the WAS authorizes the request by checking whether the client user has the required permissions to access the Web resource. If so, the Web resource is delivered to the WebSEAL server, through the Web server, which then gives it to the client user.
WebSEAL server
The policy director delegates all of the Web requests to its Web component, the WebSEAL server. One of the major functions of the server is to perform authentication of the requesting user. The WebSEAL server consults a LDAP directory. It can also map the original user ID to another user ID, such as when global single signon is used.
For successful authentication, the server plays the role of a client to WAS when channeling the request. The server needs its own user ID and password to identify itself to WAS. This identity must be valid in the security realm of WAS. The WebSEAL server replaces the basic authentication information in the HTTP request with its own user ID and password. In addition, WAS needs to know the user ID of the requesting client so that it can base its authorization decision from this user ID, and not from a WebSEAL user ID. This information is transmitted through the HTTP request, by creating a header called iv-user with the client user ID as its value.
HTTP server
The junction created in the WebSEAL server must get to the HTTP server that serves as WAS front end. However, the HTTP server is shielded from knowing that trust association is used. As far as it is concerned, the WebSEAL product is just another HTTP client, and as part of its normal routines, it sends the HTTP request to WAS. The only requirement on the HTTP server is a SSL configuration using server authentication only. This requirement protects the requests that flow within the junction.
Web collaborator
When trust association is enabled, the Web collaborator manages the interceptors that are configured in the system. It loads and initializes these interceptors when you restart your servers. When a request is passed to WAS by the Web server, the Web collaborator eventually receives the request for a security check. Two actions must take place...
- The request must be authenticated.
- The request must be authorized.
The Web authenticator is called to authenticate the request by passing the HTTP request. If successful, a good credential record is returned by the authenticator, which the Web collaborator uses to base its authorization for the requested resource. If the authorization succeeds, the Web collaborator indicates to WAS that the security check has succeeded and that the requested resource can be served.
Web authenticator
The Web authenticator is asked by the Web collaborator to authenticate a given HTTP request. Knowing that trust association is enabled, the task of the Web authenticator is to find the appropriate trust association interceptor to direct the request for processing. The Web authenticator queries every available interceptor. If no target interceptor is found, the Web authenticator processes the request as though trust association is not enabled.
For an HTTP request sent by the WebSEAL server, the WebSEAL trust association interceptor replies with a positive response to the Web authenticator. Subsequently, the interceptor is asked to validate its trust association with the WebSEAL server and retrieve the user ID of the original user client.
Trust association interceptor feature
The intent of the trust association interceptor feature is to have reverse proxy security servers (RPSS) exist as the exposed entry points to perform authentication and coarse-grained authorization, while the WAS enforces further fine-grained access control. Trust associations improve security by reducing the scope and risk of exposure.
In a typical e-business infrastructure, the distributed environment of a company consists of Web appservers, Web servers, legacy systems, and one or more RPSS, such as the Tivoli WebSEAL product. Such reverse proxy servers, front-end security servers, or security plug-ins registered within Web servers, guard the HTTP access requests to the Web servers and the Web appservers. While protecting access to the URIs, these RPSS perform authentication, coarse-grained authorization, and request routing to the target appserver.
Using the trust association interceptor feature
The following points further describe the benefits of the trust association interceptor (TAI) feature...
- RPSS can authenticate WAS users up front and send credential information about the authenticated user to WAS so that WAS can trust the RPSS to perform authentication and not prompt the end user for authentication data later. The strength of the trust relationship between RPSS and WAS is based on the criteria of trust association that is particular to a RPSS and enforced through the TAI implementation. This level of trust might need relaxing based on the environment. Be aware of the vulnerabilities in cases where the RPSS is not trusted, based on a security technology.
- The end user credentials most likely are sent in a special format as part of the HTTP headers as in the case of RPSS authentication. The credentials can be a special header or a cookie. The data that passes is implementation specific, and the TAI feature considers this fact and accommodates the idea. The TAI implementation works with the credential data and returns a string that represents the end user that WAS uses to enforce security policies.
See Also
Configuring trust association interceptors