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

Chapter 2. Planning 51

security integration and customization. Tivoli Access Manager interfaces can be

divided into three large groups:

򐂰 Tivoli Access Manager Authorization API (aznAPI)

򐂰 Tivoli Access Manager Authentication API (External Authentication Interface)

򐂰 Tivoli Access Manager Administration API

2.5.1 Tivoli Access Manager Authorization API (aznAPI)

The Access Manager aznAPI provides a standard programming and

management model for integrating authorization requests and decisions with

applications. Use of the aznAPI enables applications to utilize fine-grained

access control for application-controlled resources.

Application-specific resources may be individually defined and added to the

protected object space, and maintained in the authorization database in the

same manner that WebSEAL and other standard Access Manager blades define

their respective resources. ACLs, POPs, and authorization rules can be attached

to these application objects, and aznAPI calls can then be used to access the

Access Manager Authorization Service to obtain authorization decisions.

The authorization API provides common initialization and shutdown interface

calls for use by the service plug-ins. The authorization API also provides

additional interfaces that are specific to each of the service plug-ins.

Authorization service plug-ins

The Tivoli Access Manager authorization API supports a service plug-in model.

This model enables developers to write plug-in modules that extend the

capabilities of the Tivoli Access Manager authorization service. Developers of

third party applications can use authorization API functions that access the

service plug-in interface to perform authorization operations that are specific to

the Tivoli Access Manager secure domain.

Authorization service plug-ins are shared libraries written by application

developers. Developers create these libraries to implement a domain-specific

task for the domain-specific application. The types of data passed between the

service plug-in and the application are also domain-specific. This means that the

only restrictions on the data types are the parameter definitions in the

authorization API service functions. The data can be in a format that is unknown

to the Tivoli Access Manager authorization server. The data is passed

unchanged through the authorization service dispatcher to the authorization

service plug-ins.

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

Authorization service plug-ins are identified by a unique identification number

(ID). The service dispatcher uses the unique ID number to load the service

plug-in. The service dispatcher can optionally pass initialization parameters to

the service plug-in. The service plug-in can optionally return service information,

such as the plug-in version number, to the service dispatcher.

This modular plug-in authorization service architecture is shown on Figure 2-10

on page 53. The authorization service plug-in architecture features the following

major objects:

򐂰 Authorization service plug-in dispatcher

򐂰 Service plug-in modules

򐂰 Calling applications

When an external application needs authorization information, it sends a request

to the service dispatcher. The service dispatcher vectors the request to the

appropriate service plug-in.

Chapter 2. Planning 53

Figure 2-10 Authorization service plug-in architecture

Figure 2-10 shows that the authorization service supports these types of service

plug-ins:

򐂰 Entitlement service

򐂰 Credentials modification service

򐂰 Privilege attribute certificate (PAC) service

򐂰 Administration service

򐂰 External authorization service