Role-based security with embedded Tivoli Access Manager



Search Tips   |   Advanced Search


The J2EE role-based authorization model uses the concepts of roles and resources. For example...

getBalance deposit closeAccount
Teller granted granted  
Cashier granted    
Supervisor     granted

In the example of the banking application that is conceptualized in the previous table, three roles are defined: teller, cashier, and supervisor. Permission to perform the getBalance, deposit, and closeAccount application methods are mapped to these roles. From the example, one can see that users assigned the role, Supervisor, can run the closeAccount method, whereas the other two roles are unable to run this method.

The term, principal, within WebSphere Application Sever security refers to a person or a process that performs activities. Groups are logical collections of principals that are configured in WAS to promote the ease of applying security. Roles can be mapped to principals, groups, or both. The entry invoked in the following table indicates that the principal or group can invoke any methods that are granted to that role.

Teller Cashier Supervisor
TellerGroup Invoke    
CashierGroup   Invoke  

Frank - a principal
who is not a
member of any of
the previous

  Invoke Invoke

In the previous example, the principal Frank, can invoke the getBalance and the closeAccount methods, but cannot invoke the deposit method because this method is not granted either the Cashier or the Supervisor role.

At the time of application deployment, the Java Authorization Contract for Container (JACC) provider of Tivoli Access Manager populates the Tivoli Access Manager-protected object space with any security policy information that is contained in the application deployment descriptor. This security information is used to determine access whenever the WebSphere resource is requested.

By default, the Tivoli Access Manager access check is performed using the role name, the cell name, the application name, and the module name.

Tivoli Access Manager access control lists (ACLs) determine which application roles are assigned to a principal. ACLs are attached to the applications in the Tivoli Access Manager-protected object space at the time of application deployment.

Note: Principal-to-role mappings are managed from the WAS administrative console and are never modified using Tivoli Access Manager. Direct updates to ACLs are performed for administrative security users only.

The following sequence of events occur:

  1. During application deployment, policy information is sent to the TAM JACC provider. This policy information contains permission-to-role mappings and role-to-principal and role-to-group mapping information.

  2. The TAM JACC provider converts the information into the required format, and passes this information to the Tivoli Access Manager policy server.

  3. The policy server adds entries to the Tivoli Access Manager-protected object space to represent the roles that are defined for the application and the permission-to-role mappings. A permission is represented as a Tivoli Access Manager-protected object and the role granted to this object is attached as an extended attribute.


Related Tasks

Administer security users and roles with Tivoli Access Manager
Configure Tivoli Access Manager groups




WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.
Tivoli is a trademark of the IBM Corporation in the United States, other countries, or both.