234 Enterprise Business Portals with IBM Tivoli Access Manager
10.5.6 Trust Association Interceptor (TAI)
The Trust Association Interceptor method is used to provide single sign-on to the
WebSphere-based applications that are protected in Access Manager’s secure
domain.
Trust Association Interceptor mode is achieved by placing WebSEAL at the front
end as a reverse proxy server. From WebSEAL's management perspective, a
junction is created with WebSEAL on one end, and the WebSphere's Web server
on the other end. A request for a Web resource, stored in WebSphere's protected
domain, is submitted to WebSEAL, where it is authenticated against WebSEAL's
security realm. If the requesting user has access to the junction, the HTTP
request is transmitted to WebSphere via the junction. This HTTP request
contains a header field that contains the user ID. This field is only information
used between WebSEAL and WebSphere. WebSphere trusts the values in the
header, and validates the request using the method validateEstablishedTrust. We
refer to this as
validating the trust. If the validation is successful, WebSphere
authorizes the request. This is achieved by extracting the value of the iv_user
HTTP header, and using the method getAuthenticatedUsername. If the client
user has the required permissions to access the Web resource, the Web
resource is delivered to WebSEAL through the Web server, which then gives it to
the client.
TAI is described in more detail in “Web Trust Association Interceptor (TAI)” on
page 135.
10.6 Technical implementation
We now describe the steps needed for creating the Access Manager security
domain and Access Manager for WebSphere Application Server integration.
10.6.1 Access Manager components
This section lists the Access Manager components to be installed and the
required configuration options, but it will not provide step-by-step instructions for
such installation. Refer to the respective installation guides of Access Manager
components for step-by-step instructions. The components that need to be
installed are:
IBM Directory Server LDAP master database in the primary location core
network, unless this is already installed for WebSphere Application Server
use, which we assume to be the case in this scenario.
Access Manager Policy Server in the primary location core network.
Chapter 10. Baseline security framework 235
One or more LDAP replicas in the secondary location core network. These
will be used for authentication as well as standby master servers, should the
primary location become unavailable for some reason.
One or more LDAP replicas in the primary location core network. These will
be used for authentication as well as standby master servers.
Access Manager Authorization Servers installed on the WebSphere
Application Server machine located in the primary location core network.
Access Manager Authorization Servers installed on the WebSphere
Application Server machine located in the secondary location core network.
One or more WebSEALs in primary location Internet DMZ.
One or more WebSEALs in primary location intranet DMZ.
Web Portal Manager in primary location core network.
Web Portal Manager in secondary location core network.
A Network Dispatcher in primary location Internet DMZ.
A Network Dispatcher in primary location intranet DMZ.
A Network Dispatcher in secondary location Internet DMZ. This is used as a
hot-standby.
A Network Dispatcher in secondary location intranet DMZ. This is used as a
hot-standby.
Optional: Access Manager Policy Server stand-by replica in secondary
location core network.
The locations of the components are illustrated in Figure 10-3 on page 236. As
mentioned earlier in this chapter, the locations can be physically remote from
each other as long as they are connected by a network.
Tip: To save time later on, all LDAP traffic should be configured to be
SSL-encrypted during Access Manager installation.
236 Enterprise Business Portals with IBM Tivoli Access Manager
Figure 10-3 Access Manager components
Configuration
We assume that the components have been installed following their respective
installation guidelines. We must now configure the security components, which
include Access Manager, LDAP, Network Dispatcher, WebSphere Application
Server, and the firewalls.
The firewalls have to be configured to only allow certain types of traffic to pass.
For the Web application environment, only Web traffic should be coming into the
DMZs on either port 80 or 443.
Internet
DMZ
Secondary
Location
Internet
DMZ
Access
Manager
WebSEAL
www.yri.com
Network Dispatcher
Primary
Location
Internal Production Network (core)
Primary
Location
Internal Production Network (core)
Secondary
Location
Intranet
DMZ
Secondary
Location
Intranet
DMZ
Primary
Location
Access
Manager Policy
Server
LDAP
Database
Standby Access
Manager Policy
Server
LDAP Replica
(Standby
master)
WPM
WPM
Access
Manager
Authorization
Service
on WAS server
Access
Manager
Authorization
Service
on WAS server
LDAP Replica
(Standby
master)
Access
Manager
WebSEAL
www.yri.com
Network Dispatcher
Hot Standby
Access
Manager
WebSEAL
www.yri.com
Network Dispatcher
Hot Standby
Access
Manager
WebSEAL
www.yri.com
Network Dispatcher
Get Enterprise Business Portals with IBM Tivoli Access Manager now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
