Hot Topics - Messmer The Brain House

Tivoli
Identity
Manager
IVS
DB2
MQ
RACF
User
registry
WebSphere
Application
Server
AMWAS
z/OS
WebSphere
Application
Server
AMWAS
to configure two “junctions”—one for each
of the application servers to be contacted
by the reverse proxy on behalf of the
connecting user. When you configure these
junctions, specify:
• Tivoli Access Manager credentials (ivcred)
to be passed to the downstream
application
• The URL of the two applications
• Any other configuration settings.
In addition to handling user
authentication, the reverse proxy servers
handle two other important functions:
• Session management: The user’s
authenticated state is maintained
at the reverse proxy server allowing
the user to move from application to
application without re-authenticating.
• Authorization: Tivoli Access
Manager access control settings can
be employed to serve as one layer of
access control checking at the URL
level to protect applications that are
accessible by certain users.
TAM
Reverse
proxy
Tivoli
Access
Manager
User
administration
Figure 1 - The Computing Environment using Tivoli Access Manager, Tivoli Identity
Manager, WebSphere Application Server, and RACF.
AIX
Application
access
Easing the burden with Tivoli
Identity Manager
The use of Tivoli Access Manager for
multiple applications simplifies their use
while adding layers of protection in front of
these applications. However, there remains
the issue of managing corresponding user
information across two separate user/group
registries (RACF and an LDAP-accessible
directory). To ease the administrative
burden, you can use Tivoli Identity
Manager, configured with two “services.”
A Tivoli Identity Manager deployment
requires a DB2 database, LDAP directory,
and WebSphere Application Server
deployment in order to run the Tivoli
Identity Manager application. When these
are installed and configured, you can
configure Tivoli Identity Manager with a
service definition that communicates with
RACF on z/OS and a service definition
that communicates with the LDAPaccessible
directory server. These two
services, one using Tivoli Identity Manager’s
RACF agent and one using Tivoli Identity
Manager’s Tivoli Access Manager agent,
allow Tivoli Identity Manager to maintain
a correspondence between user definitions
in the two separate registries. By setting
up a policy in Tivoli Identity Manager to
create users in both user registries when
you add them to the environment as well
as placing these users into pre-defined
group definitions based on their job
responsibilities, you can use a single set of
processing that maintains a detailed log
of operations and manage the two user
registries in concert.
To cover end user password change and
reset, users can utilize the Tivoli Identity
Manager browser-based user interface to
request password changes and resets. Tivoli
Identity Manager supports a wide variety
of password policy checks and can be
configured with multiple challenge-response
type questions that must be answered before
a password reset is performed.
Putting it all together
As Figure 1 shows, this environment
provides ease of use for both end users
and administrators, while providing
for additional layers of access control
checking and a more feature rich set
of processing for password change and
reset. Furthermore, because Tivoli
Access Manager can be configured for
a wide variety of single and multi-factor
authentication mechanisms, access to
the applications can be set up such that
the right people can access the right
applications from the right locations.
Indeed, the whole of this deployment
is greater than the sum of its individual
parts, simplifying usage and administration
while increasing the set of security controls
available for use.
February 2006 z/OS HOT TOPICS Newsletter, Issue 14 7