WebSphere Application Server Version 6 provides embedded IBM Tivoli
Access Manager client technology to secure your WebSphere Application Server
managed resources.
The benefits of using Tivoli Access Manager described here are only applicable
when Tivoli Access Manager client code is used with the Tivoli Access Manager
server:
Note: Tivoli Access Manager code is not embedded but bundled in some
versions of WebSphere Application Server.
- Robust container-based authorization
- Centralized policy management
- Management of common identities, user profiles, and authorization mechanisms
- Single-point security management for Java 2 Platform, Enterprise Edition
(J2EE) compliant and non-compliant J2EE resources using the administrative
console for Tivoli Access Manager Web Portal Manager
- No requirements for coding or deployment changes to applications
- Easy management of users, groups, and roles using the WebSphere Application
Server administrative console
WebSphere Application Server supports the Java Authorization Contract for
Containers (JACC) specification. JACC details the contract requirements for
J2EE containers and authorization providers. With this contract, authorization
providers can perform the access decisions for resources in J2EE Version 1.4
application servers such as WebSphere Application Server. The Tivoli Access
Manager security utility that is embedded within WebSphere Application Server
is JACC-compliant and is used to:
- Add security policy information when applications are deployed
- Authorize access to WebSphere Application Server-secured resources.
When applications are deployed, the embedded Tivoli Access Manger client
takes any policy and or user and role information that is stored within the
application deployment descriptor and stores it within the Tivoli Access Manager
Policy Server.
The Tivoli Access Manager JACC provider is also called when a user requests
access to a resource that is managed by WebSphere Application Server.
Embedded Tivoli Access Manager client architecture
The previous figure illustrates the following sequence of events:
- Users that access protected resources are authenticated using the Tivoli
Access Manager login module that is configured for use when the embedded Tivoli
Access Manager client is enabled.
- The WebSphere Application Server container uses information from the J2EE
application deployment descriptor to determine the required role membership.
- WebSphere Application Server uses the embedded Tivoli Access Manager client
to request an authorization decision (granted or denied) from the Tivoli Access
Manager authorization server. Additional context information, when present,
is also passed to the authorization server. This context information is comprised
of the cell name, J2EE application name, and J2EE module name. If the Tivoli
Access Manager policy database has policies that are specified for any of
the context information, the authorization server uses this information to
make the authorization decision.
- The authorization server consults the permissions that are defined for
the specified user within the Tivoli Access Manager-protected object space.
The protected object space is part of the policy database.
- The Tivoli Access Manager authorization server returns the access decision
to the embedded Tivoli Access Manager client.
- WebSphere Application Server either grants or denies access to the protected
method or resource, based on the decision returned from the Tivoli Access
Manager Authorization Server.
At its core, Tivoli Access Manager provides an authentication and authorization
framework. You can learn more about Tivoli Access Manager, including information
that is necessary to make deployment decisions, by reviewing the product documentation.
The following guides are referenced at
http://publib.boulder.ibm.com/tividd/td/tdprodlist.html using the hyperlink
IBM Tivoli Access Manager for e-Business :
- IBM Tivoli Access Manager Base Installation Guide
This guide
describes how to plan, install, and configure a Tivoli Access Manager secure
domain. Using a series of easy installation scripts, you can quickly deploy
a fully functional secure domain. These scripts are very useful when prototyping
the deployment of a secure domain.
- IBM Tivoli Access Manager Base Administration Guide
This document
presents an overview of the Tivoli Access Manager security model for managing
protected resources. This guide describes how to configure the Tivoli Access
Manager servers that make access control decisions. In addition, detailed
instructions describe how to perform important tasks such as declaring security
policies, defining protected object spaces, and administering user and group
profiles.
Tivoli Access Manager provides centralized administration of multiple
servers.
The previous figure is an example architecture showing WebSphere Application
Servers secured by Tivoli Access Manager.
The participating WebSphere Application Servers use a local replica of
the Tivoli Access Manager policy database to make authorization decisions
for incoming requests. The local policy databases are replicas of the master
policy database. The master policy database is installed as part of the Tivoli
Access Manager installation. Having policy database replicas on each participating
WebSphere Application Server node optimizes performance when making authorization
decisions and provides failover capability.
Although the authorization server can also be installed on the same system
as WebSphere Application Server, this configuration is not illustrated in
the diagram.
All instances of Tivoli Access Manager and WebSphere Application Server
in the example architecture share the Lightweight Directory Access Protocol
(LDAP) user registry on Machine E.
The LDAP registries that are supported by WebSphere Application Server
are also supported by Tivoli Access Manager.
Note: It
is possible to have separate WebSphere Application Server profiles on the
same host configured against different Tivoli Access Manager servers. Such
an architecture requires the profiles to be configured against separate Java
Runtime Environments (JRE) and therefore multiple JREs need to be installed
on the same host.