Trust associations
Trust association enables the integration of IBM WAS security and third-party security servers. More specifically, a reverse proxy server can act as a front-end authentication server while the product applies its own authorization policy onto the resulting credentials that are passed by the proxy server.
Demand for such an integrated configuration has become more compelling, especially when a single product cannot meet all of the customer needs or when migration is not a viable solution.
In this setup, WebSphere Application Server is used as a back-end server to further exploit its fine-grained access control. The reverse proxy server passes the HTTP request to WAS that includes the credentials of the authenticated user. WebSphere Application Server then uses these credentials to authorize the request.
Trust association model
The idea that WAS can support trust association implies that the product application security recognizes and processes HTTP requests that are received from a reverse proxy server. WebSphere Application Server and the proxy server engage in a contract in which the product gives its full trust to the proxy server and the proxy server applies its authentication policies on every web request that is dispatched to WebSphere Application Server. This trust is validated by the interceptors that reside in the product 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 WebSphere Application Server from accepting requests that did not pass through the proxy server. In this case, no interceptor is needed for validating trust.
WebSphere Application Server supports the following trust association interceptor (TAI) interfaces:
- com.ibm.ws.security.web.TAMTrustAssociationInterceptorPlus
- This TAI interceptor implementation that implements the new WebSphere Application Server interface supports WebSphere Application Server Version 5.1.1
and later. The interface supports WebSEAL Version 5.1, but does not support WebSEAL Version 4.1. For an explanation of security attribute propagation, see Security attribute propagation.
(zos) Note: The TAI interceptor implementation also supports WebSphere Application Server Version 5.1.0.2 for z/OS .
- com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl
- This interceptor is new to this release. SPNEGO has replaced SPNEGO TAI as the web authenticator for WebSphere Application Server.
IBM WebSphere Application Server: WebSEAL Integration
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 the product 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 the product 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 application server.
Meanwhile, WebSphere Application Server 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, WebSphere Application Server 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 the resource 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 sign-on (GSO) is used.
For successful authentication, the server plays the role of a client to WebSphere Application Server when channeling the request. The server needs its own user ID and password to identify itself to WebSphere Application Server. 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, WebSphere Application Server must determine the credentials of the requesting client so that the application server has an identity to use as a basis for its authorization decisions. This information is transmitted through the HTTP request by creating a header called iv-creds, with the Tivoli Access Manager user credentials as its value.
HTTP server
The junction created in the WebSEAL server must get to the HTTP server that serves as the product 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 the product. The only requirement on the HTTP server is an 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 configured in the system. The web collaborator loads and initializes these interceptors when you restart the servers. When a request is passed to WebSphere Application Server 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.
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.
WebSphere Application Server Version 4 through WAS v6.x support the com.ibm.websphere.security.TrustAssociationInterceptor.java interface. WAS v7.x and later supports the com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl interface.
Trust association interceptor interface
The intent of the trust association interceptor interface is to have reverse proxy security servers (RPSS) exist as the exposed entry points to perform authentication and coarse-grained authorization, while WebSphere Application Server 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 application servers, web servers, existing 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 application servers. While protecting access to the Uniform Resource Identifiers (URIs), these RPSS perform authentication, coarse-grained authorization, and request routing to the target application server.
When a web server, such as an IBM HTTP Server, uses a TAI to communicate with WebSphere Application Server, sometimes it is essential for the TAI to know whether a request came through a web server or came directly to WebSphere Application Sever. Therefore the WAS Web container uses three HttpServletRequest attributes to provide the TAI with the certificate information for a request:
- The com.ibm.websphere.ssl.direct_connection_peer_certificates
attribute contains a X509Certificate[] object of the certificate for a direct peer.
- The com.ibm.websphere.ssl.direct_connection_cipher_suite attribute contains a string object of a direct cipher suite.
- The com.ibm.websphere.webcontainer.is_direct_connection attribute contains a boolean object that indicates whether the connection was made through a web server, or was made directly to WebSphere Application Server.
See the topic Web container request attributes for more information about these attributes.
Related tasks