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

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.