28 Certification Study Guide: IBM Tivoli Access Manager for e-business 6.0
2.1 Access management overview
Access control management plays a very significant role in any security
architecture and implementation. The purpose of access control in an overall IT
security architecture is to enforce security policies by gating access to, and
execution of, processes and services within a computing solution via
identification, authentication, and authorization processes, along with security
mechanisms that use credentials and attributes. In security systems,
authentication is distinct from authorization.
Authentication is the process of
identifying an individual who is attempting to log in to a secure domain. It gives
the answer on the question: “Who are you?”.
Authorization is the act of
determining what resources an authenticated user can access. To put it simply,
authorization provides you with a yes or no answer to the question: “Are you
authorized (do you have permission) to access/manipulate the requested
object?”. Part of the authentication process involves the creation of a credential
that describes the identity of the user. Authorization decisions made by an
authorization service are based on user credentials.
Access control information, which generally evolves around authentication and
authorization mechanisms, is handled by IBM Tivoli Access Manager.
The following products make up the IBM Tivoli Access Manager family:
IBM Tivoli Access Manager for e-business (ITAMeb)
IBM Tivoli Access Manager for Business Integration (ITAMBI)
IBM Tivoli Access Manager for Operating Systems (ITAMOS)
This book focuses on IBM Tivoli Access Manager for e-business, which provides
robust, policy-based security to a corporate Web environment. Authentication of
users, control of access privileges, auditing, single sign-on, high availability, and
logging are all essential elements of any security management solution and are
provided by Access Manager for e-business.
2.2 Core components
Access Manager for e-business, like the whole Access Manager product family,
is based on two core components:
A user registry.
authorization service consisting of an authorization database and an
authorization engine that performs the decision-making action on the request.
A user registry and an authorization service are the fundamental building blocks
upon which Access Manager provides its security service capabilities. All other
Access Manager services and components are built upon this base foundation.
Chapter 2. Planning 29
Figure 2-1 shows the general authorization model.
Figure 2-1 General authorization model
Another component that is very close to the base components is called a
resource manager. It is responsible for applying security policy to resources. The
policy enforcer component directs the request to the authorization service for
evaluation. Based on the authorization service result (approval or denial) the
resource manager allows or denies access to the protected resources.
Access Manager authorization decisions are based upon the
(PAC), which is created for each user authenticated in an Access
Manager environment, regardless of the authentication mechanism used.
Figure 2-2 on page 30 shows the implementation of the general authorization
model for an Access Manager for e-business security solution. The major
WebSEAL, as a major resource manager
Those components are described in the following sections.
Yes or No
30 Certification Study Guide: IBM Tivoli Access Manager for e-business 6.0
Figure 2-2 Access Manager for e-business basic components
Let us take a look at the basic logical flow for an authorization decisions:
1. After a user has authenticated, WebSEAL requests a Privilege Attribute
Certificate (PAC) to be created from the information in the user registry. This
certificate is bound to the specific user session and it is used as the basis for
querying the policy database during subsequent authorization decisions. This
certificate is important because authorization decisions are
context-dependent. That means, a user might be granted access to back-end
information for one type of transaction, but be rejected when attempting a
similar transaction from another application.
2. Whenever a user requests access to a back-end resource (application, data,
and so on), WebSEAL uses the PAC to query the authorization database,
which contains the protected object space maintained by the Access
Manager Policy Server, for any existing access control list (ACL), protected
object policy (POP), or authorization rule, in order to determine a
answer whether the request can be granted or has to be denied. (Access
control lists, protected object policy, and authorization rules are discussed in
2.2.2, “Policy Server” on page 32
3. If the answer is yes, the request is allowed to the Web resource.
4. The Web resource answers the request and the results are returned to the