32 Certification Study Guide: IBM Tivoli Access Manager for e-business 6.0
An LDAP-based user registry stores its data as objects and organizes it
hierarchically in a tree structure called the
Directory Information Tree (DIT). An
LDAP-based user registry can have multiple DITs. The root of every tree starts
with a
suffix. Objects are described with various attributes. The user registry for
Access Manager contains three types of objects:
򐂰 User objects, which contain basic user attributes.
򐂰 Group objects, which represent roles that user objects may be associated
򐂰 Access Manager metadata objects, which contain special Access Manager
attributes that are associated with user and group objects. The metadata
includes information that helps linking an Access Manager user ID to its
corresponding registry user object.
Tivoli Access Manager v6 has altered the way it stores a user’s metadata objects
in the directory. It has migrated to a minimal data model that minimizes the
disruption to an existing DIT structure. All data for Tivoli Access Manager can
now be stored under a separate
secAuthority=Default suffix, leaving user and
group objects that are part of the existing suffix to co-exist in the directory
Access Manager components support the use of directory replicas, peer-to-peer
(multi-master) replication, and directory partitioning. It is recommended that a
directory architecture be completed to ensure the directory environment will
perform as expected with Tivoli Access Manager and any other applications that
may wish to participate in directory services. Minimal functional and security
recommendations for the directory architecture in regard to a Tivoli Access
Manager deployment are a master-replica topology where Access Manager
resource managers (WebSEAL, Plug-in for Web servers) are configured to use
directory replicas and the Access Manager Policy Server is configured to use the
directory master(s).
2.2.2 Policy Server
The Access Manager Policy Server maintains the master authorization database
for the
secure domain. This server is primarily used for two types of
administrative activities:
򐂰 Modifying the registry to define which objects participate in the secure
򐂰 Updating the authorization database with policy definitions.
The Policy Server manages the master authorization database, which, in addition
to resource policies, contains location information about other Access Manager
servers in the secure domain. Local replicas of the master authorization
database are available for resource managers via a push/pull method initiated
Chapter 2. Planning 33
through the Access Manager runtime service. Each secure domain can only
have one Policy Server.
Authorization database
Separate from the user registry, Access Manager uses for its authorization
functions a special database containing a virtual representation of resources it
protects. Called the Tivoli Access Manager policy database, it uses a proprietary
format and contains object definitions for the
protected object space that may
represent logical or actual physical resources. Objects for different application
types may be contained in different parts of the object space, and the object
space may be extended to support new application types as required. The policy
database stores the following elements:
򐂰 Protected objects in a hierarchical tree structure (these are abstract
representations of the real objects which Access Manager intends to protect)
򐂰 Policies in 3 different forms: ACLs, POPs, and authorization rules
򐂰 Actions and action groups
򐂰 Relationships (attachments) between policies and objects
Management of the policy database is achieved with one of the following three
administration methods or a combination thereof:
򐂰 pdadmin CLI
򐂰 Web GUI Web Portal Manager (WPM)
򐂰 Administration API (C or Java)
The security policy for these resources is implemented by applying appropriate
security mechanisms to the objects requiring protection. Security mechanisms
are also defined in the authorization database, and include:
򐂰 Access control list (ACL) policy templates
򐂰 Protected object policy (POP) templates
򐂰 Authorization rules (Rules)
A security policy can be explicitly applied or inherited. The Tivoli Access
Manager protected object space supports inheritance of ACLs, POPs, and
authorization rules. This is an important consideration for the security
administrator who manages the object space. The administrator needs to apply
explicit policies only at points in the hierarchy where the rules must change, but
must be mindful that unless otherwise defined, child objects at points below will
inherit those policies.
Access control list (ACL) policy
ACLs are special Access Manager objects that define policies identifying user
types that can be considered for access, and specify permitted operations. In the
Access Manager model, ACLs are defined separately from and then attached to

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.