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

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.