Trust associations

Trust association enables the integration of IBM WebSphere Application Server 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 and more compelling, especially when a single product cannot meet all customer needs or when migration is not a viable solution. This topic gives a conceptual background behind the approach.

There is a growing demand to provide customers with a trust association solution between IBM WebSphere Application Server and other Web authentication servers that act as reverse proxy security server (IBM Tivoli Security Manager - WebSeal for Policy Director, ECommerce Server) as an entry point to all service requests. This implementation design intends to have the proxy server as the only exposed entry point. It authenticates all requests that come in and provides coarse, granularity junction point authorization.

In this setup (shown by the figure), the WebSphere Application Server is used as a back-end server to further exploit its fine-grained access control. The reverse proxy server passes to WebSphere Application Server the HTTP request 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 WebSphere Application Server 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. It should be possible, however, to configure WebSphere Application Server to strictly require all HTTP requests to go through a reverse proxy server, in which case all requests not coming from a proxy server are immediately denied by WebSphere Application Server.

IBM WebSphere Application Server and WebSeal integration

The integration of WebSeal and WebSphere Application Server security is achieved by placing WebSeal at the front-end as a reverse proxy server (see the figure). 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 WebSeal to another server.

In this setup, a request for Web resources stored in protected domain of the product is submitted to WebSeal where it is authenticated against the WebSeal security realm. If the requesting user has access to the junction, the request is transmitted to the WebSphere Application Server HTTP server through the junction, and then to the application server.

Meanwhile, the 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, the 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 WebSeal, through the Web server, which then gives it to the client user.

WebSeal

The Policy Director delegates all 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 an LDAP directory. It can also map the original user ID to another user ID, such as when global single signon (GSO) is used.

Policy Director (WebSeal)

For successful authentication, the server plays the role of a client to WebSphere Application Server when channeling the request. As such, it would need its own user ID and password to identify itself to WebSphere Application Server. This identity must be valid in the security realm of WebSphere Application Server. Thus, WebSeal replaces the Basic Auth information in the HTTP request with its own user ID and password. In addition, WebSphere Application Server would need to know the user ID of the requesting client so 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 WebSeal must get to the HTTP server that serves as the product front end. The HTTP Server is shielded however, from knowing that trust association is used. As far as it is concerned, WebSeal 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 that are configured in the system. It loads and initializes these interceptors when you restart your 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 be performed:

• 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 on the requested resource. If the authorization succeeds, the Web collaborator indicates to WebSphere Application Server that the security check has succeeded and 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. It does this by querying every available interceptor. If no target interceptor can be found, the Web authenticator processes the request as though trust association is not enabled.

For an HTTP request sent by WebSeal, 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 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, a distributed environment of a company consists of Web application servers, Web servers, legacy systems and one or more RPSS, such as the WebSeal product from Tivoli. 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 Web application servers. While protecting access to the Uniform Resource Identifiers (URIs), these RPSS perform authentication, coarse-grained authorization and route the request to the target application server. The credential formed because of the user authentication passing as a part of the request. Unfortunately, most back-end services, including WebSphere Application Server, do not understand the format of the credential information passed to them by the RPSS.

Use the Trust Association Interceptor feature

The following further describes the benefits of the Trust Association Interceptor (TAI) feature:

• Reverse proxy security servers (RPSS) can authenticate WebSphere Application Server users up front and send credential information about the authenticated user to the product so that the product can trust the RPSS to have performed authentication and not prompt the end user for authentication data another time. The strength of the trust relationship between RPSS and the product 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, but the WebSphere Application Server user should 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 Hypertext Transfer Protocol (HTTP) headers in the case of RPSS authentication. It may be a special header or a cookie. What data is passed 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 WebSphere Application Server uses to enforce security policies.