WebSphere brand IBM WebSphere Telecom Web Services Server, Version 7.1

Introduction to TAI

The Trust Association Interceptor provides a way for users to become known to WebSphere® Application Server without having to re-authenticate. The result is a simpler, yet still secure, authentication process for requests flowing throughout the network.

Overview

When a user was authenticated by an authentication system other than WebSphere Application Server, it is possible to inform WebSphere Application Server of the user's identity information without requiring the user to re-authenticate. This is known as identity assertion.

The Trust Association Interceptor component intercepts HTTP and SIP service requests to all IMS service plane components, verifies the pre-hop sender, consumes identity information passed to it in HTTP/SIP headers, and propagates this information as WebSphere Application Server-rich security information.

Supporting trust association generally implies that WebSphere Application Server processes service requests in conjunction with a reverse proxy security server (RPSS). Typically, 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.

The Trust Association Interceptor implementation does not require the presence of an RPSS, but is designed with a security proxy in mind. The Trust Association Interceptor processes all authenticated requests originating in the trusted network that contain the expected HTTP/SIP asserted identity headers. It is assumed that a user is authenticated prior to the invocation of the interceptor by the security proxy or a control plane element. The interceptors do not perform authentication themselves.

The purpose of an interceptor is to validate requests based on HTTP/SIP headers and map user information to WebSphere Application Server-rich security information. Running in trust association mode does not prohibit WebSphere Application Server from accepting requests that did not pass through the proxy server. An interceptor is not needed for validating trust. However, it is possible to configure WebSphere Application Server 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 WebSphere Application Server. In the IMS network, requests from the Internet to the service platform, coming through the Telecom Web Services Server (TWSS) Access Gateway, are allowed to bypass the security proxy, as are previously authenticated calls from the control plane.

System Structure

As this diagram shows, the solution includes a DMZ (dual firewall) to isolate protected service plane elements in the trusted domain from potential threats. A security proxy (RPSS) is implemented as a border element within the DMZ that authenticates users and propagates user information for all requests that pass through. This security proxy is not formally specified nor required by the IBM® solution, except that its interface requirements must correspond with the Trust Association Interceptor implementation.

The figure also shows that a common, custom Trust Association Interceptor exists within WebSphere Application Server to intercept HTTP and SIP traffic in the IMS-trusted domain.
Traffic flows from the Internet into TAI instances that are connected to protected elements in the service plane.

This implementation requires all IMS elements (base WebSphere Application Server, the control plane, security proxy, and the invoked service plane application) to propagate asserted identity tokens on every service request to any other service plane component within the trusted domain. This dependency is important to note because it requires coordination among all of the IBM WebSphere software for Telecom products.

X-3GPP-Asserted-Identity and P-Asserted-Identity headers are supported, by default, for HTTP and SIP requests, respectively. (Refer to the 3GPP implementation for IETF RFC 3325.) However, the type of asserted identity header is configurable for both HTTP and SIP requests to support components with different standard asserted identity headers. For example, the Aggregation Proxy component passes an X-XCAP-Asserted-Identity header to the IBM XDMS application.

The IMS control plane inserts a P-Asserted-Identity header for authenticated subscribers and may or may not go through the security proxy. All device-originating traffic is routed through the control plane (S-CSCF) before reaching the IBM service plane.

For Web services access on the service platform, the TWSS Access Gateway is used for front-end authentication and the DMZ/security proxy is circumvented.




Terms of use
(C) Copyright IBM Corporation 2009. All Rights Reserved.