Introduction to Trust Association Interceptor

You can use an external authentication proxy to protect the portal by intercepting all requests targeted for portal destinations. An authentication proxy can be implemented as a proxy server such as WebSeal in ITCAM Or it can be implemented as a plug-in to the web server or to the IBM Edge server. Ex Webagent in Netegrity siteminder.

An external authentication component authenticates users by whatever means the external authentication component considers apporpriate. You will have to use Trust Association interceptor (TAI) registered with WAS to establish a trust relationship between WAS and authentication proxy. The authentication proxy passes authenticated users ID based on establish trust.

A Trust Association Interceptor (TAI) is a mechanism by which WebSphere Application Server enables an external component to authenticate the user and to assert the identity to the WebSphere Application Server Web container.

WebSphere Application Server provides functions which the TAI uses to indicate that it is able to handle a request and that the request is already authenticated. You could think of a TAI as an adapter, which communicates with the authentication component in an unspecified way and makes the authentication decisions accessible to WebSphere Application Server through the specified TAI interface.

Whenever a request attempts to access a secured resource, WebSphere Application Server invokes the TAI, which validates that the request comes from a legitimate third-party authentication proxy and returns the user's authenticated identity to WebSphere Application Server. The TAI should return either a distinguished name (DN) or a short name. WebSphere Application Server performs a registry lookup to verify the distinguished name or convert the short name to a distinguished name before searching for group memberships for that user. If the registry lookup fails, WebSphere Application Server refuses to trust the user. If the registry lookup succeeds, WebSphere Application Server generates a Lightweight Third-Party Authentication (LTPA) token for the user and stores it as a cookie for subsequent authentication during the user's session.



Figure shows the detailed flow of control for a request that passes through an external authentication proxy. The interactions shown are the same for authentication proxies implemented as separate servers, or for proxies implemented as plug-ins for the Web server or the Edge component.

A TAI is not necessary if the third-party authentication proxy provides native WebSphere Application Server identity tokens, such as a LTPA tokens. Currently, only Tivoli Access Manager WebSEAL and Tivoli Access Manager Plugin for Edge Server provide native WebSphere Application Server identity tokens.

The authentication proxy determines the challenge mechanism, and WebSphere Portal relies on the authentication proxy to relay success or failure of the user identifier through the TAI or LTPA token. WebSphere Application Server sees all requests from the TAI as authenticated, but WebSphere Application Server and WebSphere Portal still perform a user and group lookup on each request. Even if the authentication proxy has successfully authenticated, WebSphere Application Server and WebSphere Portal deny access if they cannot query the user in the registry. For example, it is possible to have a user in an External Security Manager (ESM) who is not accessible from WebSphere Portal because WebSphere Portal is configured to one user registry, which may not be the same registry or have the same registry configuration properties as the ESM has