Level: Introductory Michael Tuton (mtuton@au1.ibm.com), Software Engineer, IBM
01 Dec 2002
The IBM Tivoli Access Manager Policy Server manages all administrative requests for users and security policy in an Access Manager environment. Therefore high availability and scalability are essential characteristics for this Access Manager server. This paper describes how to use load balancing and clustering to ensure high availability and scalability for the Access Manager Policy Server. This paper includes configuration and coding examples to assist administrators in creating this environment.
Introduction
IBM Tivoli Access Manager for e-business is a centralized policy-based
access control solution for e-business and enterprise applications. It
is an enterprise-level security product that provides a wide range of
authorization and management solutions using a common set of reusable
components.
Access Manager contains several application programming interfaces (APIs)
used for the purpose of application integration and to extend the functionality
of Access Manager. One such API is the administration API, which provides
a set of functions for the management of Access Manager users, groups
and data objects, such as access control lists and protected objects.
The Access Manager Policy Server performs these management functions.
The administration API is used by administration applications, such as
user self-registration and self-management applications, which makes the
Policy Server a more critical component within an Access Manager environment.
It’s important that the Policy Server be available to perform management
operations when requested.
This document outlines the steps required to create both standby Policy
Servers and load balanced Policy Servers. It also outlines the impact
of these configurations on other Access Manager components and administration
applications written in both C and Java. These configurations have been
tested using Access Manager version 3.9.
Access Manager administration API
Administration of Access Manager users, groups and data objects is performed
by an administration application using the administration API. The administration
API will create a connection to the Access Manager Policy Server, which
will perform the administration functions directly against either the
Access Manager User Registry or the Access Manager Authorization Database.
The administration API contains both Java and C implementations.
Figure 1. Access Manager Policy Server
Administration applications will use either the C or Java administration
API to manage Access Manager user and groups details.
The administration API works by communicating with the Access Manager
Policy Server through an encrypted TCP/IP connection. This encrypted TCP/IP
connection is referred to as the security context. This security context
provides the secure transfer of requests and data between the administration
application and the Policy Server. A security context must be established
before any administration functions can be performed.
A security context is created by issuing the C function ivadmin_context_createdefault()
or creating a new PDContext() within Java. These functions will use the
Access Manager runtime environment stored in pd.conf to determine the
SSL configuration, and the location of the Policy Server. These functions
accept the username and password of an Access Manager user that has the
necessary access rights to perform Access Manager administration operations.
Here is an example of creating a security context using the C administration
API. The security context is returned as the variable ctx.
ivadmin_context ctx;
ivadmin_response rsp;
unsigned long status;
const char *username = "admin_user";
const char *password = "admin_user_password";
status = ivadmin_context_createdefault( username, password, &ctx, &rsp );
if ( status != IVADMIN_TRUE ) {
/* The context could not be created */
/* run the necessary cleanup functions and exit */
handleError( rsp, "Error creating security context" );
}
|
The hard coded values for username and password are here just for illustration.
After a security context has been established this password should be
zeroed out for security reasons. The code for handleError()
is not included in this example.
Here is an example using the Java administration API to create a security
context.
//Create locale for US English
Locale myLocale = new Locale("ENGLISH","US");
String adminName = “admin_user”;
String adminPwd = “admin_user_password”;
char [] adminPassword = adminPwd.toCharArrary();
URL configFileURL = new URL(file:///c:/WebSphere/AppServer/PDPerm.properties);
|
myContext
PDContext
PDContext =new (myLocale,
adminName,
adminPassword,
configFileURL);
|
The Java PDContext requires the location of the Access Manager
configuration file that was created by the
SvrSslCfg class.
Administration applications
With organizations attempting to make it easier for users to sign up to
their services, more applications that provide self-registration and self-care
are appearing. These applications give users the ability to quickly create
and manager their own accounts within an organization and have instant
access to some of their services, without the requirement to fill out
paperwork or contact a helpdesk.
In addition to self-care applications, organizations also have the requirement
to integrate and customize Access Manager administration procedures to
conform with their own administration environment. Which can range from
z/OS to WebSphere based Java applications.
For these types of applications to work in an Access Manager environment,
they will use the administration API.
Figure 2. Administration API Applications
An administrator can then use 3270 green screen applications, some web
client or even web services to connect to the organizations administration
services. This administration server can then make calls to the Policy
Server using the administration API to manage the Access Manager environment.
Policy server clusters
In order to increase the availability of the Access Manager Policy Server,
or to distribute the load of administration operations across several
Policy Servers, it’s suggested to create Policy Server clusters.
Policy Server Clusters are made up of one or more Policy Servers, in
any of the following configurations:
- Highly available Policy Servers, containing one master Policy Server
and several standby Policy Servers.
- Load Balanced Policy Servers, containing multiple Policy Servers balancing
the load of user and groups operations.
- A combination of both highly available and load balanced Policy Servers.
All of these cluster configurations require a cluster address, which
is managed by a TCP/IP routing device, such as the WebSphere Edge Server,
Network Dispatcher component. The TCP/IP router must ensure that affinity
between the administration client and Policy Server are maintained, as
the administration API uses SSL for communication and the associated security
context is only valid for one Policy Server at a time. All servers in
any cluster configuration will share the user registry; this document
doesn’t contain any details of clustering or load balancing the
user registry within an Access Manager environment.
Some cluster configurations attempt to use DNS to redirect requests to
the standby Policy Server. Since the automatic re-establishment of Access
Manager components (that support it) will not re-resolve the IP address
of the Policy Server, using DNS will result in all Access Manager components
being re-started, as the DNS change will change the IP address of the
Policy Server.
Highly available policy servers
Within a highly available cluster, there is one master Policy Server with
several standby Policy Servers. Each standby Policy Server contains a
replica of the Authorization Database and a copy of the master Policy
Server configuration, which has the ability to take over the master Policy
Server function in case of a critical failure where the master Policy
Server is unable to perform any tasks.
Figure 3. Highly available policy server cluster
An administration application will maintain a security context with the
master Policy Server until such time as the master Policy Server fails
and the standby Policy Server takes over the administration functions.
When this occurs, the TCP/IP router will route the administration operations
to the standby Policy Server, after the standby Policy Server has been
promoted to the new master.
Since each administration application must maintain a security context
with just a single Policy Server, then when the master Policy Server fails
and the standby Policy Server takes over, a new security context must
be re-established. The C administration API and Java administration API
will handle this situation differently.
Failover using the C administration API will require the administration
application to re-establish the security context by calling the
ivadmin_context_createdefault()
function. Where the Java administration API will automatically restore
the security context with the next call made to a Java administration
API method.
Access Manager Policy Servers will not automatically replicate the authorization
database between each other, in order to maintain a copy of the authorization
database on the standby Policy Server the Access Manager Authorization
Server is used. The Authorization Server will automatically replicate
the authorization database from the master Policy Server, this copy of
the authorization database can be used by the standby Policy Server when
being promoted to the master Policy Server.
This option is best used for redundancy only. There are no performance
benefits from running multiple administration applications through the
one Policy Server. However the Policy Server can handle multiple simultaneous
administration requests in parallel.
Load balanced policy servers
A load balanced Policy Server cluster will balance the user and group
requests across several Policy Servers. Only the user and group
operations can be load balanced, any operations on the Authorization Database
will be lost.
The load balanced Policy Servers should be a separate set of servers
than the master and standby Policy Servers. This separates out the load
balanced Policy Servers from the master Policy Server. It’s important
that the master Policy Server is the only Policy Server used to download
the Authorization Database, as it’s the only server with the most
up to date copy of the Authorization Database. Typically in this configuration
the Policy Servers are just gateways to the user registry, providing a
high level set of functions to operate on Access Manager User Registries.
The Authorization Database in this case, is usually empty and not used,
which means that delegated management is not supported.
Figure 4. Load balancing user operations
Each administration application can only establish a security context
with one Policy Server at a time. This cluster configuration is ideal
where there are multiple administration applications all performing user
and groups operations. The TCP/IP router must ensure that the connection
between each administration application and Policy Server is maintained.
If the TCP/IP router decides to switch Policy Servers on the administration
client, then this should only be done when one of the Policy Servers has
failed.
Since the security context of an administration client is maintained
by the administration application, then when the TCP/IP router has redirected
the administration function to another Policy Server, the administration
application must create a new security context with the new Policy Server.
The Java administration API will automatically restore the security context,
where the C administration API will not.
There is a high overhead associated with creating administration API
security contexts, so this task must only be done when necessary.
This option is best used for high performance situations, as there are
multiple dedicated servers all running Policy Servers for processing user
and group administration requests only. Where, each Policy Server can
handle multiple administration requests all in parallel. However since
these Policy Servers don’t contain a copy of the authorization database
they’re unable to make any authorization decisions on which administrations
can perform certainly administration requests, these requests are left
to the administration application, rendering this option unavailable for
any situation that has modified the default management access control
rules, such as delegated management.
Combined policy server clusters
Combining both the highly available and load balanced clusters
together requires that the standby Policy Server take on a dual role as
both a load balanced user administration server and the standby Policy
Server. This configuration requires that the TCP/IP router handle multiple
cluster addresses. One for the highly available Policy Servers and another
for the load balanced Policy Servers. The advantage of this configuration
is that additional Policy Server hardware is not required for the load
balancing task. It’s important to keep the cluster addresses separate
for highly available and load balanced configurations, as the master Policy
Server is the only server guaranteed to have the latest up to date copy
of the authorization database. Access Manager components that require
an up to date replica of the authorization database will use just the
highly available cluster address, such as WebSEAL, where user administration
applications will use the load balanced cluster address.
Figure 5. Highly available and load balanced policy servers
This configuration has the advantage that delegated management is supported,
as the Authorization Database may contain rules about delegate management
on the standby Policy Server. In this situation the Authorization Database
cannot be empty on the standby Policy Server, as the standby Policy Server
must know how to enforce access to different domains of users based on
an administrators delegation rights. In this situation the standby Policy
Server is running in parallel with the master Policy Server but is not
configured to notify Access Manager servers about changes to the authorization
database.
When a failure occurs with the master Policy Server then the standby/load
balanced Policy Server can take on the role of the master Policy Server
by using it’s replicated Authorization Database and turning on update
notifications.
The impact of a failure on administration applications is the same as
the other configurations. The advantage is that the architecture is simplified
and less hardware is required to provide this solution.
This option is best used when both performance and redundancy are required.
The Policy Servers will both have a copy of the authorization database,
where any changes made to the default management access control list are
enforced on all Policy Servers. However the authorization database on
the standby/load balanced Policy Server will need to be manually kept
up to date by using the authorization database from the Authorization
Server.
The performance of this option will not be as good as using load balanced
Policy Servers, as the Policy Servers are playing a dual role, and will
handle additional traffic. However considering fewer servers are required,
then the cost benefits may outweigh the performance hit for those environments
where only a moderate amount of administration transactions are required.
Highly available policy server configuration
The highly available Policy Server configuration requires several Access
Manager packages, which are:
- PDRTE, the Access Manager Runtime Environment
- PDAuth, the Access Manager Authorization Server
- PDMgr, the Access Manager Policy Server
The PDRTE package contains the base Access Manager binaries and libraries
required by all Access Manager servers. The PDAuth package contains the
Access Manager Authorization Server, while this server isn’t used
to make authorization decisions within the highly available cluster environment,
it’s used for replicating the master Authorization Database from
the master Policy Server.
The PDMgr package contains the Policy Server.
To configure the Access Manager standby runtime environment the following
tasks are performed.
- Install the PDRTE package
- Install the PDAuth package
- Configure the PDRTE and PDAuth components to use the Policy Server
cluster address.
- Install the PDMgr package
- Install any Access Manager fixpacks now
- Do not configure the PDMgr component
To configure the standby Policy Server (PDMgr) component perform these
steps.
- Copy these files from the master Policy Server to the same location
on the standby Policy server.
etc/ivmgrd.conf
keytab/ivmgrd.sth
keytab/ivmgrd.kdb |
- To create the standby Policy Server Authorization Database use the
replica downloaded by the Authorization Server on the standby Policy
Server.
# cp db/ivacld.db db/master_authzn.db
Do not start the standby Policy Server, unless the master Policy Server
has been shutdown.
To keep the standby Authorization Database in sync with the master Policy
Server, perform the equivalent operation at some interval.
# cp db/ivacld.db db/master_authzn.db
To promote the standby Policy Server perform the following
steps.
- Ensure that the standby Authorization Database is in sync with the
master Authorization Database by taking a copy of ivacld.db (the Authorization
Server on the standby Policy Server)
# cp db/ivacld.db db/master_authzn.db
- Change the TCP/IP load balancer to direct administration API requests
to the standby Policy Server.
- Stop the master Policy Server, if it's still running
- Start the standby Policy Server
To demote the standby Policy Server the following steps
must be performed.
- Ensure that the Authorization Database on the new master Policy Server
is in sync with the standby Policy Server. This is done by taking a
copy of the db/master_authzn.db file from the standby Policy Server
and storing it in the same location on the new master Policy Server.
- Change the TCP/IP load balancer to direct administration API requests
to the new master Policy Server.
- Stop the standby Policy Server.
- Start the new master Policy Server
The impact of promoting or demoting the Policy Servers
will have the same effect as re-starting the Policy Servers, causing all
Access Manager applications to loose their security context with the Policy
Server. For any administration services to resume, a new security context
must be established. The re-starting of the Policy Server will have the
following effects on Access Manager components and servers:
- pdadmin – the security context is automatically re-established
without the administrator having to re-authenticate.
- Web Portal Manager (WPM) – the administrator will need to re-authenticate
to the WPM.
- C administration API applications – the application will need
to re-create the security context.
- Java administration API applications – the security context
is automatically re-established with the next call to the Java administration
API.
- Access Manager Servers – other Access Manager servers will automatically
re-establish a security context with the Policy Server without any interruption
to the services they perform.
Load balanced policy server configuration
The load balanced Policy Server configuration requires several Access
Manager packages, which are:
- PDRTE, the Access Manager Runtime Environment
- PDMgr, the Access Manager Policy Server
The Authorization Server is not used in this configuration, as there
is no requirement to keep the Authorization Database in sync with the
master Authorization Database. As this database is not used to store protected
data objects.
To configure the load balanced Policy Server perform these tasks.
- Install the PDRTE packages
- Configure the PDRTE packages against the master Policy Server
- Install the PDMgr package
- Install any Access Manager fixpacks now
- Do not configure the PDMgr component
To configure the load balanced Policy Server (PDMgr) component perform
these steps.
1. Copy these files from the master Policy Server to the same location
on the load balanced Policy Server
etc/ivmgrd.conf
keytab/ivmgrd.sth
keytab/ivmgrd.kdb
|
2. To create the empty Authorization Database required by the Policy
Server issue this command.
For all applications that need to use the load balanced Policy Servers,
modify the master-host entry to point to the Policy Server cluster. This
change is made in the
etc/pd.conf file.
[manager]
#
# Master server configuration
#
# Hostname of the Policy Server.
master-host = <load balanced cluster address>
Where the <load balanced cluster address> is the hostname of the Policy Server cluster. |
The Policy Servers can now be started.
When an administration application is sent to another Policy Server it
has the same effect as re-starting the Policy Server. Applications must
re-establish a security context with the Policy Server, the C and Java
administration APIs will handle this situation differently.
Combined policy server configuration
The combined Policy Server configuration requires several Access Manager
packages, which are:
- PDRTE, the Access Manager Runtime Environment
- PDAuth, the Access Manager Authorization Server
- PDMgr, the Access Manager Policy Server
Since this configuration is a combination of the highly available and
load balanced configurations, then the required packages will match the
highly available configuration. The main difference is the procedure used
when the standby Policy Server is promoted and demoted.
To configure the Access Manager standby runtime environment the following
tasks are performed.
- Install the PDRTE package
- Install the PDAuth package
- Configure the PDRTE and PDAuth components to use the Policy Server
cluster address.
- Install the PDMgr package
- Install any Access Manager fixpacks now
- Do not configure the PDMgr component
To configure the standby Policy Server (PDMgr) component perform these
steps.
1. Copy these files from the master Policy Server to the same location
on the standby Policy server.
etc/ivmgrd.conf
keytab/ivmgrd.sth
keytab/ivmgrd.kdb
|
2. Turn off update notifications on the standby Policy Server
# sbin/pdconf –f etc/ivmgrd.conf setentry ivmgrd auto-database-update-notify no |
For all applications that need to use the load balanced Policy Servers,
modify the master-host entry to point to the Policy Server cluster. This
change is made in the etc/pd.conf file.
[manager]
#
# Master server configuration
#
# Hostname of the Policy Server.
master-host = <load balanced cluster address>
Where the <load balanced cluster address> is the hostname of the Policy Server cluster.
|
Start the standby Policy Server now.
To promote the “standby” Policy Server perform the following
steps.
- Ensure that the standby Authorization Database is in sync with the
master Authorization Database by taking a copy of ivacld.db (the Authorization
Server on the standby Policy Server)
# cp db/ivacld.db db/master_authzn.db |
- Change the TCP/IP load balancer to direct administration API requests
to the standby Policy Server for the “highly available”
cluster.
- Stop the master Policy Server, if it’s still running
- Turn on update notifications on the standby Policy Server
# sbin/pdconf –f etc/ivmgrd.conf setentry ivmgrd auto-database-update-notify yes |
- Start the standby Policy Server
To demote the standby Policy Server the following steps must be performed.
- Ensure that the Authorization Database on the new master Policy Server
is in sync with the standby Policy Server. This is done by taking a
copy of the db/master_authzn.db file from the standby Policy Server
and storing it in the same location on the new master Policy Server.
- . Change the TCP/IP load balancer to direct administration API requests
to the new master Policy Server.
- Stop the standby Policy Server
- Start the new master Policy Server
- Turn off update notifications on the standby Policy Server
# sbin/pdconf –f etc/ivmgrd.conf setentry ivmgrd auto-database-update-notify no |
- Start the standby Policy Server.
Summary
The IBM Tivoli Access Manager Policy Server has the ability to be replicated
and clustered throughout an organizations security infrastructure, resulting
in increased scalability and availability to applications utilizing Access
Manager user and protected resource administration functions.
Acknowledgements
Special thanks goes out to Shane Weeden and Norman Field for their input and initial procedures for maintaining standby Policy Servers in an Access Manager environment. Also thanks to Paul Ashley and Sridhar Muppidi for their careful review and suggestions for this paper.
About the author  | | | Michael Tuton is an Consulting IT Specialist working in the Tivoli Security Business Unit (part of the IBM Software Group). He currently works at the Tivoli Gold Coast Lab. |
Rate this page
| 
