Introduction

The TAMeb Session Management Server manages user sessions across Tivoli Access Manager servers and allows for the implementation of session policy across the participating servers.

Using the TAMeb Session Management Server allows TAMeb WebSEAL and TAMeb Plug-in for Web Servers to share a unified view of all current sessions and permits authorized users to monitor and administer user sessions.

The TAMeb Session Management Server also makes available session and log in statistics, for example, the last time a user logged in and the number of failed attempts to log in since the last successful log in. This information is generally useful when displayed to users at the time of log in to alert of any potential illegal activity on their account. However this information can also be used to implement a more sophisticated account policy not available in TAMeb 6.0.

The TAMeb SMS, a J2EE™ application running on IBM® WebSphere® Application Server (WAS) 6.0, stores this information using a JDBC datasource. A persistent data store such as a DB2® database can be accessed and used off-line for automation of account management procedures.

This paper describes how TAMeb 6.0 can be used to implement a security policy where inactive accounts are proactively and automatically disabled or even deleted. An example application is built and the implementation and configuration procedure is documented in detail.

Back to top

Prerequisites

This paper assumes that the TAMeB 6.0 base components and TAMeB 6.0 WebSEAL are correctly installed and configured. It also requires that TAMeB 6.0 SMS (Session Management Server) is installed and running on WAS 6.0.2 (or later) and it has been configured to use an IBM DB2 database for storing log in activity data.

For details about installing TAMeb 6.0 base components, the Session Managemenet Server and the login activity database, see the " IBM Tivoli Access Manager for e-business: Installation Guide "

Back to top

An automatic account management system high-level overview

This section outlines the high level architecture to be used for the implementation of an automatic account management service. In such a system, there exists a number of key components:

1. The end-user: This is the owner of the account that is managed.
2. An authentication system: One ore more Web or Reverse Proxy servers that drive the authentication process.
3. The LDAP server: This contains the user account information.
4. An account management system: This handles the login information and performs automatic account management and notification.
5. The mail system: This handles the notification of e-mails.

The architecture for such a system would resemble what is reported in Figure 1 :

High-level authentication process flow with WebSEAL and SMS

In a TAMeb 6.0 environment where WebSEAL uses the SMS for session management, the following actions are performed during a user authentication:

1. WebSEAL binds to the LDAP server to verify the user credentials.
2. If the user credentials are correct, WebSEAL contacts the SMS in order to validate the user's session in respect to the session policy.
3. The SMS updates the Login database with the user statistics.

Implementation of account policy in TAMeb 6.0 and possible extensions

The TAMeB 6.0 Session Management Server allows the strict implementation of an n-strike log in policy. This permits TAMeB 6.0 to temporarily or definitively disable an account whenever a configurable number of failed log ins have been performed among all the WebSEAL servers in the same session realm.

Unused accounts (when the owner has no further need of that account even if he still has all the rights belonging to that account) are not only costly, as they still allocate resources, but are also a security weakness. There is less usage monitoring of an unused account, hence less accuracy for claims of abuse. IT security personnel need to implement a security policy where it is mandatory to disable or delete an account if it is not used for a number of days.

TAMeB 6.0 does not natively have an administrative command to implement such a policy; however it offers all the required data and facilities to implement it almost immediately. The remainder of this article describes how to develop and install an Account Management Server within an IBM Tivoli Access Manager 6.0 secure domain.

Back to top

The Account Management Server architecture and connections

This section describes how an automatic account management service can be realized using components and middleware that are already available in a classic implementation of TAMeB 6.0 where the TAMeB 6.0 SMS is also used. Other services like an SMTP Mail service are usually available in any private intranet or can be accessed using a commercial or free mail service provider over the Internet.

As reported in Figure 3, we named the implementation of this service Account Management Server (AMS). The AMS uses the following resources to perform its tasks:

1. Using the JDBC API, the AMS queries and handles account login statistics created by the TAMeB SMS.
2. Using the TAMeB Java™ API, it performs TAM administrative commands through the TAM Policy Server, to disable or delete the TAM account when needed.
3. Using the JNDI API, it connects to the TAM LDAP user registry and retrieves users' e-mail addresses.
4. Using the JavaMail API, it contacts the SMTP server to send notification e-mail to administrators or alert messages to the account owners.

Back to top

The Account Management Server implementation

This section provides a high-level description on how the Account Management Server has been developed. The source code is self-documented and can be obtained from the Downloads section.

The AMS server is a J2EE application composed of a couple of stateless session beans whose relationship, as reported in Figure 4, is as follows:

1. The Account Manager bean acts as a facade to the SMS login database, as well as to the LDAP Server and the TAM Policy Server.
2. The Account Controller bean, which is a TimedObject, provides methods to periodically check the SMS login database and take the appropriate management actions.

Back to top

The Account Management Server business logic

The core business logic of the AMS can be summarized as follows:

1. If an account has been inactive for more than X days (the user has not performed a successful log in during the last X days), then the Account Management Server contacts the TAM Policy Server and disables the account. The result of this action is sent via e-mail to the administrator. If an account has been found inactive in the SMS log in database but there is no related user in the TAM user registry, then the account is considered an orphan and clean up is done in the SMS database to reconcile it with the TAM user registry.
2. If an account has been inactive and disabled for more than Z days (where Z > X), then the Account Management Server contacts the TAM Policy Server to delete the account definitively. The result of this action is sent via e-mail to the administrator.
3. If an account has been inactive for more that X-Y days (where Y is the number of days the user is alerted before his account is disabled), then the Account Management Server sends an alert e-mail for notification to the account owner and the result of this notification is sent to the Administrator.

Parameters and options that define the business logic can be set in a configuration files but also changed at runtime; this will be described later in the Account Management Server Administration section.

Figure 5 shows the activity diagram of the controller bean while Figure 6 represents the class diagram. For those interested in seeing how these diagrams are actually translated into Java code, we recommend that you import the AccountManagementService_project.zip, available from the Downloads section, as a project interchange archive into Rational® Application Developer.

Back to top

The Account Management Server configuration

The installation of the Account Management Server requires several configuration steps as it uses different resources. This section provides an overview of each component configuration. For a step-by-step description, see the Configuration.pdf in the Downloads section.

WebSphere configuration

Here is a summary of the configuration steps to be performed on WebSphere Application Server:

1. A new Mail Session within the WebSphere default Mail Session Provider
2. A new URL within the WebSphere default URL Provider
3. A new datasource using DB2 JDBC XA driver
4. A new service integration Bus and a couple of destination Buses
5. A new JMS Queue Connection Factory and a couple of JMS Queues

The interactions with the TAM Policy Server to disable or delete an account, and with the SMTP Server to deliver e-mail notifications to the users, can potentially be very slow. Consequently, we developed the Account Controller bean to asynchronously handle the account management actions and asynchronously publish the associated results. This strategy minimizes the interaction with the SMS log in database, sensibly reducing the probability of interference with the normal activities of the SMS.

The asynchronous coupling between the Account Controller and the Account Management and the User Notification services is obtained by exchanging messages (Management Actions) over a Service Integration Bus, through JMS queues, as shown in Figures 7 and 8.

The Account Management Server has its own configuration file that needs to be defined as a URL provider in WebSphere software. We named this file amsconfig.properties. Figure 9 shows the URL provider definition.

Account Management Server configuration

The configuration file has different sections, one for each service that the application uses. The LDAP server configuration section is where to specify the LDAP server host, the user ID and password for binding, and the user suffix for base search. This information is used by the application to retrieve users' e-mail addresses:

                

#-------------------------------------------------------------------------
# IBM Directory Server (LDAP) Configuration
#-------------------------------------------------------------------------
# - ldap.server.host           The LDAP Server name (default localhost)
# - ldap.server.port           The LDAP Server port (default 389)
# - ldap.server.userid         LDAP Server admin username
# - ldap.server.password       LDAP Server admin password
# - ldap.server.users.dn       LDAP user's suffix (default cn=users,o=ibm,c=it)
#-------------------------------------------------------------------------------
 

The TAM configuration settings section defines parameters required to contact the TAM Policy Server via the TAM Administration API. This is used to disable or delete an account.

                

#--------------------------------------------------------------------------------
# Tivoli Access Manager for eBusiness (TAMeb) Server Configuration
#--------------------------------------------------------------------------------
# - tam.server.pdperm       URL of the PdPerm.properties file
# - tam.server.userid       TAMeb Server admin username
# - tam.server.password     TAMeb Server admin password
# - tam.server.users.dn     TAMeb user's suffix (default cn=users,o=ibm,c=it)
#--------------------------------------------------------------------------------
 

The tam.server.pdperm setting is a URL for the properties file that is created when configuring the TAM Java runtime for the application. In particular, it is the file created when running the com.tivoli.pd.jcfg.SvrSslCfg utility. For details about configuring Tivoli Access Manager 6.0 Java administration API consult The IBM Tivoli Access Manager Administration Java Classes Developer Reference

The AMS Application settings section defines the default values for the logic of the application. Those parameters can be modified at runtime as reported in The Account Management Server administration section; however the default values are taken from this section of the configuration file.

                
#--------------------------------------------------------------------------------
# Application settings
# - automatic.account.check.enabled   true if the AMS server must automatically
#                                     check inactive accounts, false otherwise.
# - account.check.period              the period of time between two consecutive
#                                     checks of the managed accounts [min].
# - last.login.max.age.before.disable the number of days after which a inactive
#                                     account must be disabled.
# - last.login.max.age.before.delete  the number of days after which a disabled
#                                     account must be deleted.
# - user.notification.enabled         true if an early arning must be sent to the
#                                     user before disabling the inactive account,
#                                     false otherwise.
# - user.warning.days                 how many days before disabling an account a
#                                     notification is sent to the account owner [day].
# - result.polling.period             the period of time between two consecutive
#                                     checks of the results of asynchronously executed
#                                     account management actions [min].
# - admin.notification.enabled        true if a report of management action results
#                                     must be sent to the administrator, false otherwise.
# - admin.email.address               the e-mail address where reports must be delivered.
#---------------------------------------------------------------------------------
 

The AMS internal application settings section defines the inner functionality of the application. Generally, if the average number of accounts that are inactive is not very high, it is also possible to choose a synchronous implementation of the Action Handler and the Result Handler components. To do this, simply uncomment the synchronous result and action handler keys.

                
#------------------------------------------------------------------------------------
# Internal Application Settings
#------------------------------------------------------------------------------------
# - service.toolkit.impl   Business services implementation
# - user.registry.impl     User Registry implementation
# - access.manager.impl    Access Manager implementation
# - mail.sender.impl       Mail sender service implementation
# - action.handler.impl    Management action handler implementation; possible values are:
#    - com.ibm.tam.ams.biz.action.ActionHandler$SynchImpl to synchronously  handle
#      the management actions.
#    - com.ibm.tam.ams.biz.action.ActionHandler$AsynchImpl to asynchronlusly handle
#      the management actions (default).
# - result.handler.impl    Management action result handler implementation
#    - com.ibm.tam.ams.biz.action.ResultHandler$SynchImpl to synchronously handle
#      the results of management actions.
#    - com.ibm.tam.ams.biz.action.ResultHandler$AsynchImpl to asynchronously handle
#      the results of management actions (default).
#-------------------------------------------------------------------------------------
# WARNING: comment all the properties to use the System in production mode
#  for a synchronous implementation comment out
#result.handler.impl=com.ibm.tam.ams.biz.action.ResultHandler$SynchImpl
#action.handler.impl=com.ibm.tam.ams.biz.action.ActionHandler$SynchImpl
#-------------------------------------------------------------------------------------

#service.toolkit.impl=com.ibm.tam.ams.biz.DummyServiceToolkit
#user.registry.impl=com.ibm.tam.ams.biz.sec.DummyUserRegistry
#access.manager.impl=com.ibm.tam.ams.biz.sec.DummyAccessManager
#mail.sender.impl=com.ibm.tam.ams.biz.mail.DummyMailSender
#action.handler.impl=com.ibm.tam.ams.biz.action.DummyActionHandler
#action.handler.impl=com.ibm.tam.ams.biz.action.ActionHandler$SynchImpl
#result.handler.impl=com.ibm.tam.ams.biz.action.DummyResultHandler
#result.handler.impl=com.ibm.tam.ams.biz.action.ResultHandler$SynchImpl
 

Database configuration

The AMS server uses the Result Handler class, both synchronous and asynchronous implementations, to store relevant information about the outcome of management actions in a database table.

This table, named AMSACTIONINFOTABLE, needs to be created within the SMS log in database. It must be in a 1:1 relation with the AMSMSUSERINFOTABLE table used by the SMS to store log in info statistics.

The AMS hence requires a datasource to connect to the SMS log in database. This datasource must use the XA DB2 Universal JDBC Driver-Compliant Provider. Datasources created under this provider support the use of XA to perform two-phase commit processing.

It is possible to share the datasource used by the SMS if the AMS application is deployed within the same WebSphere Application Server and the SMS datasource has been defined to use the XA DB2 Universal JDBC Driver.

Figure 10 shows the JDBC provider datasource definition.

The SQL code listing below creates the AMSACTIONINFOTABLE and a foreign key for the AMSMSUSERINFOTABLE. The AMSMSUSERINFOTABLE has already been created by the TAM SMS installation and configuration. (Before running the SQL query, it is necessary to verify and eventually modify the schema according to the schema defined for the SMS. Refer to the Prerequisites section.)

                

DROP TABLE DB2ADMIN.AMSACTIONINFOTABLE;
CREATE TABLE DB2ADMIN.AMSACTIONINFOTABLE
  (USERNAME VARCHAR(250) NOT NULL,
   ACTION_TYPE VARCHAR(32),
   ACTION_EXEC_DT TIMESTAMP,
   ACTION_RES_MSG VARCHAR(256),
   ACTION_STATUS VARCHAR(16),
   NUM_ACTION_EXECS INTEGER NOT NULL DEFAULT 0,
   ADMIN_NOTIFIED SMALLINT NOT NULL DEFAULT 0
);

ALTER TABLE DB2ADMIN.AMSACTIONINFOTABLE
  ADD CONSTRAINT PK_ACTION_INFO PRIMARY KEY (USERNAME);

ALTER TABLE DB2ADMIN.AMSACTIONINFOTABLE
  ADD CONSTRAINT FK_ACT_USR FOREIGN KEY (USERNAME)
  REFERENCES DB2ADMIN.AMSMSUSERINFOTABLE(USERNAME)
  ON DELETE CASCADE
  ON UPDATE NO ACTION;
      

Figure 11 shows a sample content of the AMSMSUSERINFOTABLE table. The AMSMSUSERINFOTABLE is updated by the SMS any time there is a user log in into WebSEAL. The SMS however does not delete the entries in this table.

The AMSACTIONINFOTABLE table is updated by the AMS server when the Account Controller bean publishes results of the account management actions. The AMS implements also a reconciliation procedure with the TAM user registry so that the AMSACTIONINFOTABLE or the AMSMSUSERINFOTABLE and the TAM user registry are synchronized. Figure 12 shows a sample content of the AMSACTIONINFOTABLE table.

Back to top

The Account Management Server administration

The Account Management Server, as shown in Figure 13, has an administrative interface to change the disable account policies and the notification option with respect to the default values from the configuration file. This modification takes effect immediately and there is no need to restart the application. Using this interface, it is even possible to request an immediate check without waiting for the next schedule.

The administrative interface can also be used to show the results of a query on the log in database. A report of management actions performed on a specific date is shown in Figure 14.

In our implementation the administrative interface does not have any declarative or programmatic security defined. In order to allow authenticated and authorized users to access to the AMS administrative interface, the application can be protected by a WebSEAL junction. For WebSEAL junction details, consult the WebSEAL Administration Guide

Back to top

The Account Management Server notification

The Account Management Server has the capability to send notification e-mails. If this feature is enabled for the administrator and for each user (see Figure 11), then the administrator receives a report of the activity performed by the AMS server while the user receives an alert notification e-mail.

The notification mail for the administrator would resemble what is reported in Figure 15.

If an alert message is sent to the account owner that his account will be invalidated or deleted, a message like the one in Figure 16 is what the user will see.

Back to top

Summary

In this article, we discussed how it is possible to leverage IBM WebSphere 6.0 services and resources to design and develop an application that extends the IBM Tivoli Access Manager for eBusiness 6.0 account security policies, which proactively and automatically disables or deletes inactive accounts. This simple application should greatly assist with any compliance requirements relating to user accounts.

Back to top

Downloads

Information about download methods          Get Adobe® Reader®

Note

1. This is a configuration guide describing how we setup our environment to deploy and test the AMS application.

Resources

Learn

• "IBM Tivoli Access Manager for eBusiness 6.0 infocenter"
  
  
• In the Tivoli area on developerWorks, get the resources you need to advance your skills in the Tivoli arena.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  

Get products and technologies

• Download IBM product evaluation versions and access application development tools and middleware products from DB2, Lotus®, Rational, Tivoli, and WebSphere.
  
  

Discuss

• Participate in the discussion forum.
  
  
• Check out developerWorks blogs and get involved in the developerWorks community.
  
  

About the authors

Gianluca Gargaro is an IT Specialist working in the Security Products Support Team in Rome, Italy. His area of expertise includes application, network and enterprise security. He is an IBM Certified Solution Advisor and IBM Certified Advanced Deployment Professional for Tivoli Security.

Patrizio Trinchini is a Software Engineer at the Rome Industry Solutions Lab. He has several years experience in the design and development of distributed Java applications. His previous experience includes working on several projects in the monitoring, licensing and security areas. He is currently working on a meter management application in the Energy and Utility sector of IBM.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Prerequisites
• An automatic account management system high-level overview
• The Account Management Server architecture and connections
• The Account Management Server implementation
• The Account Management Server business logic
• The Account Management Server configuration
• The Account Management Server administration
• The Account Management Server notification
• Summary
• Downloads
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: Tivoli Access Manager Enterprise Single Sign-on
• Demo: Demo: Tivoli Access Manager for Enterprise Single Sign-On solution overview
• Briefing: Introduction to Tivoli service management environment
• Buy: Tivoli Access Manager Enterprise Single Sign-on

Dig deeper into Tivoli on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers