The Trust Association Interceptor (TAI)
security component is intended to enhance the overall authentication
security for the IBM® WebSphere® software for Telecom.
Implementation scenarios describe how the TAI interacts
with the Access Gateway and Service Platform components.
When setting up the
Trust Association Interceptor for
Telecom Web Services Server,
consider the following:
- Install the TAI on
the same server as the Service Platform components.
The Service Platform uses a trusted network security model using the TAI.
- Avoid installing the TAI on
the Access Gateway server
unless you have a way of ensuring that none of the incoming messages
require authentication–for example, a firewall is in place, or the Access Gateway is
called only from inside a trusted network. Note that the Access Gateway uses
a single sign-on scheme for transactions with the Service Platform components and
optionally with the Service Policy Manager.
- The TAI is
used by other components, for example IBM XDMS and Presence Server.
About the scenarios
The following
sections depict common system configurations in which components are deployed
in production and in scaling/high-availability (HA) scenarios. Each scenario
is presented with the following conditions:
The
Telecom Web Services Server constituent
components are deployed and scaled separately from each other. There
are two cluster descriptions for the
Telecom Web Services Server configuration:
- Access Gateway
- Service Platform components
Access Gateway
The
following diagram illustrates a scenario in which three
Access Gateway nodes receive SOAP/HTTP traffic that flows through a converged proxy
pair or a load balancer pair.
Note: - The WebSphere Application Server converged
proxy or any third-party load balancer can be deployed pair-wise (for
high availability).
- IBM Tivoli® Composite Application
Management (ITCAM) users communicate directly with the Access Gateway node
for purposes of collecting Performance Monitoring Infrastructure (PMI)
data from that node.
- If the converged proxy is also used in the overall Telecom Web Services Server configuration,
then the same instance could also be used for HTTP traffic through
the Access Gateway;
otherwise, IBM HTTP Server (IHS) or another load balancer
can be used.
- The Access Gateway performs
authentication. Requests hit the Access Gateway directly
from the Internet, without a reverse proxy security server (RPSS)
being invoked. The Access Gateway can
also accept requests from other Service Platform components,
where it maintains and propagates the asserted identity header that
is present.
- The Access Gateway adds
an X-3GPP-asserted identity header to the HTTP request.
Service Platform components
It
is recommended that the Service Policy Manager (SPM)
be co-deployed with the Service Platform components,
but it may also be deployed in a standalone cluster as well. If deployed
in a standalone cluster, the configuration is similar to that for
the Access Gateway cluster.
The service implementation functionality can be mixed and matched
on the service platform using normal WebSphere Application Server application
deployment.
The following diagram illustrates a scenario in
which three Service Platform nodes, with the
Trust Association Interceptor deployed
on each one, receive SOAP/HTTP traffic that flows through a converged
proxy pair or a load balancer pair.
Note: - The Converged Proxy must be used if there are SIP services deployed;
otherwise, IHS or another load balancer can be used
- Only the Access Gateway supports
Performance Monitoring Infrastructure (PMI) utilized by the IBM Tivoli
Composite Application Management (ITCAM) for J2EE operations component.
- The Trust Association Interceptor is
in front of the Service Platform and searches for the asserted identity
header.
- The Service Policy Manager uses
a single sign-on scheme for transactions with other Telecom Web Services Server components.
It can use the Trust Association Interceptor for
transactions with the network, but this is not required.