Chapter 5. Programming 189
5.2 Authorization API overview
Using the Tivoli Access Manager authorization application programming
interface (aznAPI), you can program Tivoli Access Manager applications and
third-party applications to query the Tivoli Access Manager authorization service
for authorization decisions. The Tivoli Access Manager authorization API is the
interface between the server-based resource manager and the authorization
service; it provides a standard model for coding authorization requests and
decisions. The aznAPI lets you make standardized calls to the centrally
managed authorization service from any developed application. The aznAPI
supports two implementation modes:
򐂰 Remote cache mode
In remote cache mode, you use the aznAPI to call the Tivoli Access Manager
authorization server, which performs authorization decisions on behalf of the
application. The authorization server maintains its own cache of the replica
authorization policy database.
򐂰 Local cache mode
In local cache mode, you use the aznAPI to download a local replica of the
authorization policy database. In this mode, the application can perform all
authorization decisions locally.
The aznAPI shields you from the complexities of the authorization service
mechanism. Issues of management, storage, caching, replication, credentials
format, and authentication methods are all hidden behind the aznAPI. The
aznAPI works independently from the underlying security infrastructure, the
credential format, and the evaluating mechanism. The aznAPI makes it possible
to request an authorization check and get a simple yes or no recommendation in
return.
5.2.1 Configuration of an aznAPI application
The aznAPI application must establish its own authenticated identity within the
IBM Tivoli Access Manager (Tivoli Access Manager) secure domain in order to
request authorization decisions from the Tivoli Access Manager authorization
service. Before you run the aznAPI application for the first time, you must create
a unique identity for the application in the Tivoli Access Manager secure domain.
In order for the authenticated identity to perform API checks, the application must
be a member of at least one of the following groups:
ivacld-servers This group membership is needed for applications using
local cache mode.
remote-acl-users This group membership is needed for applications using
remote cache mode.
190 Certification Study Guide: IBM Tivoli Access Manager for e-business 6.0
When the application wants to contact one of the secure domain services, it must
first log in to the secure domain.
Use the
svrsslcfg utility to accomplish this task. Run this utility before initializing
the aznAPI. The svrsslcfg utility performs the following tasks:
򐂰 It creates a user identity for the application by combining the server name
with the local TCP/IP host name.
򐂰 It creates an SSL key file for that user.
򐂰 It adds the user to the ivacld-servers group for a server type of local, or to the
remote-acl-users group for a server type of remote.
Configuring a Java application into the secure domain
Java applications that use Tivoli Access Manager security must be configured
into a Tivoli Access Manager secure domain. Tivoli Access Manager provides a
utility class called com.tivoli.pd.jcfg.SvrSslCfg that can be used to accomplish the
necessary configuration and unconfiguration tasks.
The SvrSslCfg class is used to create a Tivoli Access Manager user account for
an application server and to store the server’s configuration and certificate
information in local configuration and keystore files. After obtaining the necessary
information, use the SvrSslCfg option -action config to create the Tivoli Access
Manager application name, the configuration file, and the keystore file.
Configuring an application server creates user and server information in the user
registry, and creates local configuration and keystore files.
Again, Tivoli Access Manager supports Java application servers in either remote
mode or local mode.
As we have already shown in Figure 2-10 on page 53, the Tivoli Access Manager
aznAPI supports a service plug-in model. The Tivoli Access Manager
authorization service recognizes and registers service plug-ins by reading entries
in the aznAPI client configuration file. When the application initializes the aznAPI,
the authorization server parses the configuration file. The dispatcher resolves the
location of each service plug-in, and loads each service plug-in. The
azn_svc_initialize() function returns an error if a service plug-in is not configured
correctly or if the service plug-in module cannot be located.
Note: The svrsslcfg command line interface and the SvrSslCfg Java utility are
not interchangeable. Do not use the svrsslcfg command line interface to
create configuration files that are to be used with Java applications. Do not
use the SvrSslCfg Java class to create configuration files for use by C
applications.

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.