Certification Study Guide: IBM Tivoli Access Manager for e-business 6.0

58 Certification Study Guide: IBM Tivoli Access Manager for e-business 6.0

user’s credential. The groups could then be synchronized from the foreign

user registry into the Access Manager user registry. Another way to perform

this type of mapping is to have the EAI map the users into a specified set of

static groups in the Access Manager user registry. Using this technique,

authentication is performed against a foreign user registry and the group

memberships in the foreign user registry can be reflected in the Access

Manager credential. ACL authorization can now be performed at the group

level. It is important to be aware that user level authorization is still not

possible since the EAI is still returning a fixed user ID to WebSEAL.

2.5.4 Java API for Access Manager

The IBM Tivoli Access Manager Runtime for Java component includes the Java

language version of a subset of the Tivoli Access Manager API. The

authorization API consists of a set of classes that provide Java applications with

the ability to interact with Tivoli Access Manager to make authentication and

authorization decisions.

Java security

The Tivoli Access Manager authorization Java classes provide an

implementation of Java security code that is fully compliant with the Java 2

security model and the Java Authentication and Authorization Service (JAAS).

The Tivoli Access Manager authorization Java classes are built around JAAS

and the Java 2 security model. The Tivoli Access Manager API closely follows

the Java 2 permission model. The Tivoli Access Manager authorization API Java

classes also support a completely Java-compliant usage of the Tivoli Access

Manager authorization check that is outside of the Java 2 and JAAS framework.

2.5.5 Access Manager-based authorization for Microsoft .NET

IBM Tivoli Access Manager provides integration and support for implementing

Access Manager-based authorization for Microsoft .NET applications. Access

Manager APIs are exposed at the .NET Common Language Runtime level. This

exposes the functionality to all .NET languages such as Managed C++, C#, and

Visual Basic .NET.

2.6 Placing components in a network

There is no unique configuration of Access Manager components in a network.

No solution uses the same number of Access Manager components and some of

the components are not mandatory. The placement of Access Manager

components represents a set of choices, but in this book we show some general

Chapter 2. Planning 59

security guidelines. Keep in mind that you cannot simply separate network

configuration issues from Access Manager. While Access Manager components

perform their duties extremely well, good sense dictates that they must operate

in an environment that prevents them from being bypassed and protects them

from undue exposure to other forms of attack.

Today networks are divided into several zones. Network boundaries are used to

isolate networking zones with differing security policies. These boundaries are

created to implement restrictions on the type of traffic that is allowed in a zone. In

its simplest case, a firewall creates boundaries between two or more networks

and stands as a shield against unwanted penetrations into your environment.

Figure 2-11 Network zones and Access Manager components

The number of zones depends on the existing security policies and the level of

security that needs to be implemented. Typical network configurations consist of

three to five zones:

򐂰 Internet, outside network (uncontrolled zone)

򐂰 Internet DMZ (controlled zone)

򐂰 Intranet (controlled zone)

No Access Manager

component should be

deployed in an uncontrolled

network. It is also generally

unsafe for Access Manager

components to

communicate with one

another across an

uncontrolled network

without using secure

communication

mechanisms (such as SSL).

Usually, only

WebSEAL or other

Access Manager

resource

managers (such as

the Web server

plug-in) should be

placed in a

controlled network

zone.

The specific level of

trust in an internal

network dictates what

Access Manager

components may be

deployed within them.

Organizations may set

up specialized

restricted zones for

production systems,

which could include

Web and application

servers, and various

Access Manager

components, such as

the user registry, the

Session Management

Server, Policy Proxy

Servers, or internally

used WebSEALs.

Some organizations

set up special

networks to separate

various management

components from

production systems.

The Access Manager

Policy Server and the

master LDAP server

might be installed in

such a network.

Internet

Uncontrolled

Zone

Internet DMZ Intranet

Controlled

Zone

Controlled

Zone

Production

Network

Restricted

Zone

Management

Network

Secured Zone

LESS SECURE MORE SECURE

Public Managed Trusted