Chapter 4. Configuration and customization 123
input. WebSEAL manipulates the contents of the appropriate entry in the
WebSEAL session cache by:
1. Removing the administrators WebSEAL session cache data and storing it in
a separate location
2. Inserting the switched-to user’s cache data, including the users credential, in
place of the administrator’s cache data
WebSEAL sends a
redirect to the browser for the destination URL supplied in the
switch user form. The request is processed normally, using the user’s credential.
The administrator can continue to make other requests. All authorization
decisions for these requests are based on the credential of the user. The
administrator ends the switch user session using the standard Tivoli Access
Manager
pkmslogout utility.
Upon successful logout:
1. The user’s cache data is deleted.
2. The administrator’s original cache data (and credential) is restored.
3. The administrator is returned to the original page from which the switch user
form was requested.
4.4.3 Re-authentication
Tivoli Access Manager WebSEAL can force a user to perform an additional login
(re-authentication) to ensure that a user accessing a protected resource is the
same person who initially authenticated at the start of the session. Forced
re-authentication provides additional protection for sensitive resources in the
secure domain. Re-authentication can be activated by:
򐂰 A protected object policy (POP) on the protected object.
򐂰 Expiration of the inactivity timeout value of a WebSEAL session cache entry.
Re-authentication is supported by the following WebSEAL authentication
methods:
򐂰 Forms-based (user name and password) authentication
򐂰 Token authentication
򐂰 External authentication interface
In addition, a custom user name and password module can be written to support
re-authentication. Re-authentication assumes that the user has initially logged in
to the secure domain and that a valid session (credential) exists for the user.
During re-authentication, the user must log in using the same identity,
authentication method, and authentication level that generated the existing
credential. WebSEAL preserves the user’s original session information, including
124 Certification Study Guide: IBM Tivoli Access Manager for e-business 6.0
the credential, during re-authentication. The credential is not replaced during
re-authentication. During re-authentication, WebSEAL also caches the request
that prompted the re-authentication. Upon successful re-authentication, the
cached data is used to rebuild the request.
Creating and applying the re-authentication POP
Forced re-authentication based on security policy is configured by creating a
protected object policy (POP) with a special extended attribute named
reauth.
You can attach this POP to any object that requires the extra protection provided
by forced re-authentication. Remember that all children of the object with the
POP also inherit the POP conditions. Each requested child object requires a
separate re-authentication.
The following example illustrates creating a POP called
restricted with the reauth
extended attribute and attaching it to an object (salary.html):
pdadmin> pop create restricted
pdadmin> pop modify restricted set attribute reauth true
pdadmin> pop attach /WebSEAL/hostA/junction/salary.html secure
Anyone attempting to access salary.html is forced to re-authenticate using the
same identity and authentication method that generated the existing credential. If
the user requesting the resource is unauthenticated, the POP forces the user to
authenticate. No re-authentication is necessary for this resource after successful
initial login.
Re-authentication based on session inactivity
Re-authentication based on session inactivity is enabled by a configuration
stanza entry and is activated by the expiration of the inactivity timeout value of a
session cache entry. A user’s session is normally regulated by a
session
inactivity
value and a session lifetime value. When WebSEAL is configured for
re-authentication based on session inactivity, the user’s session cache entry is
flagged whenever the session inactivity timeout value expires. The session cache
entry (containing the user credential) is not removed. The user can proceed to
access unprotected resources. However, if the user requests a protected
resource, WebSEAL sends a login prompt. After successful re-authentication,
the inactive session
flag is removed and the inactivity timer is reset.
If re-authentication fails, WebSEAL returns the login prompt again. The session
cache entry remains
flagged and the user can proceed to request unprotected
resources until the session cache entry lifetime value expires. Two other
conditions can end a user session:
1. The user can explicitly log out.
2. An administrator can terminate a user session.

Get Certification Study Guide: IBM Tivoli Access Manager for e-business 6.0 now with the O’Reilly learning platform.

O’Reilly members experience live online training, plus books, videos, and digital content from nearly 200 publishers.