Tivoli Access Manager security for WebSphere Application Server

 

+

Search Tips   |   Advanced Search

 

WebSphere Application Server (WAS) V6 provides embedded IBM Tivoli Access Manager (TAM) client technology to secure WAS managed resources. The benefits of using TAM described here are only applicable when TAM client code is used with the TAM server:

  • Robust container-based authorization

  • Centralized policy management

  • Management of common identities, user profiles, and authorization mechanisms

  • Single-point security management for resources using the administrative console for TAM Web Portal Manager

  • No requirements for coding or deployment changes to applications

  • Easy management of users, groups, and roles using the WebSphere Application Server administrative console

Note that TAM code is not embedded but bundled in some versions of WAS.

WAS v6.x supports the Java Authorization Contract for Containers (JACC) specification, which details the contract requirements for J2EE containers and authorization providers. With this contract, authorization providers can perform the access decisions for resources in J2EE V1.4 application servers such as WAS. The TAM security utility that is embedded within WAS v6.x is JACC-compliant and is used to:

  • Add security policy information when applications are deployed

  • Authorize access to WAS-secured resources.

When applications are deployed, the embedded Tivoli Access Manger client takes any policy and or user and role information that is stored within the application deployment descriptor and stores it within the TAM Policy Server.

The TAM JACC provider is also called when a user requests access to a resource that is managed by WAS.

 

Embedded TAM client architecture

  1. Users that access protected resources are authenticated using the TAM login module that is configured for use when the embedded TAM client is enabled.

  2. The WAS container uses information from the J2EE application deployment descriptor to determine the required role membership.

  3. WAS uses the embedded TAM client to request an authorization decision (granted or denied) from the TAM authorization server. Additional context information, when present, is also passed to the authorization server. This context information is comprised of the cell name, J2EE application name, and J2EE module name. If the TAM policy database has policies that are specified for any of the context information, the authorization server uses this information to make the authorization decision.

  4. The authorization server consults the permissions that are defined for the specified user within the TAM-protected object space. The protected object space is part of the policy database.

  5. The TAM authorization server returns the access decision to the embedded TAM client.

  6. WAS either grants or denies access to the protected method or resource, based on the decision returned from the TAM Authorization Server.

At its core, TAM provides an authentication and authorization framework. We can learn more about TAM, including information that is necessary to make deployment decisions, by reviewing the product documentation. Start with the following guides, available at http://publib.boulder.ibm.com/tividd/td/tdprodlist.html:

  • IBM TAM Base Installation Guide

    This guide describes how to plan, install, and configure a TAM secure domain. Using a series of easy installation scripts, one can quickly deploy a fully functional secure domain. These scripts are very useful when prototyping the deployment of a secure domain.

  • IBM TAM Base Administration Guide

    This document presents an overview of the TAM security model for managing protected resources. This guide describes how to configure the TAM servers that make access control decisions. In addition, detailed instructions describe how to perform important tasks such as declaring security policies, defining protected object spaces, and administering user and group profiles.

TAM provides centralized administration of multiple servers.

The previous figure is an example architecture showing WASs secured by TAM.

The participating WASs use a local replica of the TAM policy database to make authorization decisions for incoming requests. The local policy databases are replicas of the master policy database. The master policy database is installed as part of the TAM installation. Having policy database replicas on each participating WAS node optimizes performance when making authorization decisions and provides failover capability.

Although the authorization server can also be installed on the same system as WAS, this configuration is not illustrated in the diagram.

All instances of TAM and WAS in the example architecture share the Lightweight Directory Access Protocol (LDAP) user registry on Machine E.

The LDAP registries that are supported by WAS are also supported by TAM.

Note: It is possible to have separate WAS profiles on the same host configured against different TAM servers. Such an architecture requires the profiles to be configured against separate Java Runtime Environments (JRE) and therefore multiple JREs need to be installed on the same host.