74
Novell Access Manager 3.1 SP2 J2EE Agent Guide
n
ov
do
cx (e
n)
16
Ap
ril 20
10
requests from end-user Web browsers are intercepted by Novell Access Manager enriched with
supporting information, passed on by Access Manager to WebSphere Application Server and
offered to the TAI for validation.
“How Does the TAI Module Works?” on page 74
“Methods” on page 75
“Configuration Properties” on page 75
“Selective Deployment” on page 76
“Update Behavior” on page 76
“Implementing the Trust Association Interceptor Module” on page 77
“Configuring eDirectory” on page 77
“Configuring the WebSphere Application Server” on page 77
“Configuring Novell Access Manager” on page 80
How Does the TAI Module Works?
The TAI module provides role provisioning services to WAS and WPS.The supporting information
placed in each request consists of the following fields:
Secret Key String:
This is used by the TAI to validate that the process has actually gone
through Access Manager.
User Name:
This is the short user name retrieved by Access Manager when the user
authenticates.
User ID:
This is the long user name in LDAP format.The fully qualified distinguished name of
the authenticated user within the LDAP store to which Access Manager, WebSphere
Application Server, and WebSphere Portal Server are connected.
Cache Key:
This is the identifier for the user session, as generated by Access Manager.
User Roles:
This is a list of the iManager roles for the user.
All fields are fixed strings, stored within the
HttpServletRequest
as retrievable HTTP headers.
When TAI receives a request, it takes the following actions:
It verifies that the request contains a secret key value that matches the value specified in the
TAI configuration.
It prepares for the username, user ID, and cache key to be passed on to WebSphere Application
Server, as attributes (
WSCREDENTIAL_SECURITYNAME
,
WSCREDENTIAL_UNIQUEID
and
WSCREDENTIAL_CACHE_KEY
) of a subject within a
TAIResult
. If a cache key was not provided
by Access Manager, the TAI generates one that is based on the current server system time.
It filters certain roles out of the list provided by Access Manager, and formulates a full LDAP
group DN for each of those. The resulting set of group distinguished names is placed in the
TAIResult
as the
WSCREDENTIAL_GROUPS
subject attribute. WebSphere Application Server
can perform a lookup in an LDAP store to which it is connected.
It filters other roles out of the Access Manager list, constructs another LDAP group DN for
each of them, and then establishes the actual membership for the groups by performing LDAP
query and update transactions against the LDAP store with which it is configured. With the
group objects prepared in this way, WebSphere Portal Server can subsequently query the
LDAP store for the members, thus indirectly consuming the role information previously
gathered by Access Manager.
Содержание Access Manager 3.1 SP 2
Страница 4: ...4 Novell Access Manager 3 1 SP2 J2EE Agent Guide novdocx en 16 April 2010...
Страница 8: ...8 Novell Access Manager 3 1 SP2 J2EE Agent Guide novdocx en 16 April 2010...
Страница 44: ...44 Novell Access Manager 3 1 SP2 J2EE Agent Guide novdocx en 16 April 2010...
Страница 83: ...Preparing the Applications and the J2EE Servers 83 novdocx en 16 April 2010...
Страница 108: ...108 Novell Access Manager 3 1 SP2 J2EE Agent Guide novdocx en 16 April 2010...