. 65
( 87 .)


more comprehensive security model that is separate from the underlying
WAS/WP platform. Bene¬ts for doing this include the following:

Support for heterogeneous environments and servers within a single
and consistent security model
Ability to manage virtually any resource
Central management of security information
Con¬gurable session management (for example, session time-outs)
Full support for user provisioning
De¬nition of security and access control rules based on users, roles,
dynamic roles, and even through rules that match data in a user
context with conditions that determine whether the user should have
access to a particular resource
Support for personalized Web and portal content using a consistent
rule set regardless of the underlying provider
Policies and personalization based on IP addresses
Enhanced security attributes (from an attack perspective)
Multi-grained security (that is, the ability to de¬ne ¬ne-grained
access control on some resources and coarse-grained access at the
same time)
Support for SSO (see next section)

Third-Party Authentication and SSO Architectures
SSO Architectures are primarily based on a third-party authentication server
that is inserted in your infrastructure as a reverse proxy. Because it serves
as a reverse proxy, it intercepts all requests regardless of which server the
request is ultimately dispatched to. Because you will have so many appli-
cations in a portal environment, the concept of a third-party authentica-
tion server says that it makes no sense for any one of these systems and
applications to be the main authentication engine; instead, a dedicated au-
thentication server is used to authenticate the user. Once authenticated, the
authentication server places the user information in a token that is passed
to all systems and applications. These systems look for the information
within the token and trust this information. This means that the systems and
WY009-20 WY009-BenNatan-v1.cls May 17, 2004 18:56

388 Chapter 20

applications rely on the authentication server and trust the authentication
server rather then needing to reauthenticate the user.
In a WP environment, a third-party authentication server is also trusted
by WP itself. The mechanism by which this occurs is actually a WAS fea-
ture that WP implicitly inherits. Regardless of whether you use SiteMinder
or TAM, SSO works through a Trust Association Interceptor (TAI). A TAI
is an interface that is part of the WAS security model. It is implemented
by a Java class that is installed on WAS (or WP in your case); its task is
to validate that the request is legitimate by inspecting agreed upon infor-
mation that is stored by the authentication server in the request. Once a
user is authenticated, the authentication server creates a token; in an HTTP
request this information may be placed as speci¬c headers in the request.
When the request reaches WP the TAI is invoked. The TAI knows which
headers need to be checked and retrieves the correct information from the
headers. Because it trusts the authentication server, it applies the appropri-
ate credentials within WP and WP continues as though it is the one who
performed the authentication. The TAI should return either a Distinguished
Name (DN) or a short name. WP then performs a lookup within the user
registry to verify the DN (potentially ¬rst converting the short name into a
DN if the TAI returns a short name). If the lookup fails, WP will refuse to
trust the information and will refuse the request; otherwise, an LTPS token
is created and stored as a cookie for subsequent requests within the session.
In order to correctly support user identi¬cation and authorization in addi-
tion to authentication, both WP and the authentication server must share the
same user registry. Speci¬cally, an LDAP server maintaining user informa-
tion and pro¬les needs to be registered with both WP and the authentication
Once both WP and the security server share the same user registry, you
can go one level further than authentication (hence we use the term security
server here for the ¬rst time). Access rights within WP are usually adminis-
tered using access control lists and are stored within WP™s administration
database. However, you can also con¬gure an external security manager
such as TAM and SiteMinder to protect WP resources. Both TAM and Site-
Minder can be used to manage authorization policies for WP resources such
as portlets and pages in addition to WAS constructs such as servlets and
EJBs. This is mostly based on URL paths and the mapping of URLs to users
and roles.

Integrating TAM with WP
In addition to supporting all the features described in the previous section,
TAM also supports some WAS-speci¬c security features. WAS supports an
IBM proprietary SSO token called Lightweight Third Party Authentication
WY009-20 WY009-BenNatan-v1.cls May 17, 2004 18:56

Integrating Security and Identity Management Tools 389

(LTPA). This is the preferred SSO token method in WAS and therefore in
WP. LTPS is naturally also supported by TAM and hence the TAM/WP
security integration is very comprehensive.
You should consider using TAM security rather than straightforward WP
security for a variety of reasons. First, TAM implements a comprehensive
SSO architecture that will cover most if not all of your back-end systems
very naturally. In addition, TAM will provide you with a higher level of
security for the following reasons:

TAM includes a secure proxy server (WebSEAL) that has been
deployed in very large installations and has proven to be very
effective. The WebSEAL proxy acts as an additional security layer
within your DMZ, breaking direct access between browsers (and
potential attackers) and your core application servers.
TAM supports multiple authentication schemes including user
name/passwords, various forms of certi¬cates, tokens, and
TAM supports cross-domain SSO.
TAM supports not only WP but also other WebSphere products such
as WebSphere Everyplace (see Chapter 24).
WebSEAL is a layer that can be hardened to a great extent without
affecting important platforms such as WP (which would be much
harder to lock down and harden).
TAM can easily be integrated with existing user registries.
TAM supports rule-based decisions.
TAM supports full audit capabilities.

Installing TAM Support on WP
The ¬rst thing you need to do in order to enable TAM-to-WP integra-
tion is to set up the TAM TAI. This TAI is not unique to WP and the in-
stallation steps are identical to those you would follow when integrating
WAS and TAM. Log in to the WAS Administration Console and click Se-
curity ➪ Authentication Mechanisms ➪ LTPA. Scroll down, as shown in
Figure 20-1, and click Trust Association.
Make sure that trust association is enabled and click Interceptors. Also
make sure that your interceptor is de¬ned as com.ibm.ws.security.web
.WebSealTrustAssociationInterceptor; if it is not, click New and
select this class.
Next you need to set up the LDAP settings, including the security server
ID, password, host, port, base DN, bind DN, and bind password. Click
WY009-20 WY009-BenNatan-v1.cls May 17, 2004 18:56

390 Chapter 20

Figure 20-1 Opening the Trust Association Screen within the WAS Administration

Security ➪ User Registries ➪ LDAP and enter these values as shown in
Figure 20-2. Finally, you will need to restart WAS.
While authentication using TAM is really set up within WAS, authoriza-
tion via TAM is a WP-speci¬c process and involves WP resources such as
portlets and pages. This requires you to con¬gure the connection between
WP and TAM by running the following routine from the TAM installation:
<TAM_ROOT>/sbin/pdjrtecfg -action config -java_home <WAS_ROOT>/Java/jre

Then con¬gure an SSL connection between WAS and TAM, create a key
¬le and a properties ¬le, as well as an agreed-upon user name and groups.
To do so, run the following command from your command line:
<WAS_ROOT>/Java/jre/bin/java com.tivoli.mts.SvrSslCfg <USER NAME>

Next, add the following line to services.properties:
com.ibm.wps.services.authorization.ExternalAccessControlService =
WY009-20 WY009-BenNatan-v1.cls May 17, 2004 18:56

Integrating Security and Identity Management Tools 391

Figure 20-2 Con¬guring the LDAP User Registry.

Next, edit externalAccessControlService.properties within
your TAM installation and change the value of accessControl to equal
Next, edit portallogin.config. There are two sections called
WpsNewSubject and WpsSubjectExists. In each section you need to
add the following line at the end:
Com.ibm.websphere.security.auth.module.proxy.WSLoginModuleProxy required

Restart the portal server and you are done.

Disabling WP User Provisioning and Manipulation
When using an external security manager such as TAM you should also
ensure that all user provisioning occurs through TAM. Because TAM is the
main security manager all new users must be registered through TAM, and
user provisioning directly within WP will create situations in which users
have registered and received acknowledgment by WP but when they try to
log in they will be denied. Therefore, you must disable WP™s user creation
WY009-20 WY009-BenNatan-v1.cls May 17, 2004 18:56

392 Chapter 20

capabilities. In addition, you should disable the User Manager portlet. You
can do both of these tasks by removing the user management portlets when
logged in as an administrator.

Setting Up SSO
Before proceeding on to discuss Netegrity SiteMinder with WP, let™s look
at some speci¬c (and common) scenarios in which you would use security
and identity management tools. You would use a tool such as TAM or Site-
Minder when deploying numerous applications and data sources through
WP. In this section we will walk you through some speci¬c examples of
such a deployment. Speci¬cally, we will walk you through a few scenarios
involving the integration of SAP systems with TAM and WP. The discus-
sion is similar in concept (although different in details) when SiteMinder is
SAP is one of the largest software vendors in the world and is most well
known for its Enterprise Resource Planning (ERP) solution. It maintains the
largest market share of packaged solutions and most large corporations run
SAP software. In this section we show you two scenarios that are common
when integrating SAP solutions in an existing WP environment using TAM.
Because such integration may involve presenting SAP functionality through
WP and because SAP systems manage their own security, you will need
to set up an SSO environment that includes WP and the SAP software”
through TAM. This means that in addition to what you already know in
terms of WP and TAM, you will have to set up a trust relationship between
SAP servers and TAM.
Because the SAP solution set is so broad, an integrated solution can be
implemented in many ways and you can choose to use or omit many SAP
components. While we cannot cover all options in this section, we will
describe two different scenarios that are fairly typical”both in the SAP
world as well as in cases in which other suites are being used (for example,
PeopleSoft and Siebel) The ¬rst scenario describes the integration of the
mySAP.com Internet-enabled infrastructure and the second describes the
integration of the SAP Enterprise Portal. In both cases the assumption is
that you are using a back-end component of SAP such as various SAP R/3
modules (for example, ¬nance and warehousing) or SAP BW (the business
information warehouse).

mySAP.com Integration
Before we can show you the steps involved in integrating mySAP.com or
the mySAP Workplace, let™s review the elements involved in the mySAP.com
architecture, and speci¬cally SAP™s Internet Transaction Server (ITS).
WY009-20 WY009-BenNatan-v1.cls May 17, 2004 18:56

Integrating Security and Identity Management Tools 393

Figure 20-3 mySAP.com Architecture.

Figure 20-3 shows a typical layered scheme of mySAP.com. The back
end consists of various application modules within SAP R/3 and SAP BW.
In addition to these servers the Workplace Server is a component built on


. 65
( 87 .)