4.3 Configuring Applications on the WebSphere Server

4.3.1 Configuring for Authentication

You need to create policies that deny access to the anonymous user. You can do this either with the web.xml file within the .war file or with Access Manager policies. In Access Manager, you deny access to the anonymous user by creating an authorization policy that denies access to anyone who has not been assigned the authenticated role. Anonymous users who haven’t authenticated do not have this role, and users who have authenticated to Access Manager are automatically assigned this role.

If you have pages that call Enterprise JavaBeans that are protected, you should assign a policy to these pages that denies access to users who have not authenticated.

4.3.2 Configuring Security Role to User/Group Mapping

You need to configure security role for user or group and map the roles.

  1. In the Integrated Solution Console, Select Applications > Websphere Enterprise Applications > Payrollapp > Detail Properties >Security Role to User/Group Mapping.

  2. Click Map Users tab.

  3. Select Manager role check box to map the user.

  4. Enter the user name in the search string. For Example - admin

  5. Click Search.

  6. Select the users from the Available List to the Selected List.

  7. Click OK.

  8. Click Save to configure the changes.

  9. The mapped user is displayed for the selected role.

4.3.3 Configuring for User RunAs Roles

An Enterprise JavaBean deployment descriptor can state that an Enterprise JavaBean must run with a particular role. The the sample application (PayrollApp.ear) includes such a statement in its descriptor:

<security-identity>
    <run-as>
       <role-name>Manager</role-name>
    </run-as>
</security-identity>

Without configuring WebSphere to map a RunAs role to a user, WebSphere ignores this statement. If a user is mapped to a RunAs role, the agent cannot know which J2EE roles the user has unless the role is also mapped.

To configure mapping for RunAs roles, complete the following during WebSphere deployment:

  1. In the Integrated Solution Console, Select Applications > Websphere Enterprise Applications > Payrollapp > Detail Properties > User RunAs Roles.

  2. Enter the user name and the password. For Example - admin

  3. Select the User role check box. For Example - Manager.

  4. Click Apply.

  5. Click OK.

  6. Click Save to configure the changes.

  7. The mapped user is displayed for the selected role.

The WebSphere server uses this mapping to assign a user to execute an Enterprise JavaBeans method.

When you configure the WebSphere mapping for RunAs roles, WebSphere updates the J2EE agent configuration on the WebSphere server. To ensure that this was updated properly or to update the configuration manually, see Section 9.8, Authorization Fails in the WebSphere Application.

NOTE:The J2EE Agent may not send the user roles to application when running on WebSphere. To fix this issue, follow the steps provided in Section 9.8, Authorization Fails in the WebSphere Application.

4.3.4 Configuring the Trust Association Interceptor Module for WebSphere Application

The Trust Association Interceptor (TAI) module is a plug-in for WebSphere Application Server. It is a Java class, packaged into a Java Archive file (JAR) that is placed within the application code sections of the WebSphere Server file system.

The TAI module, which has a class name of com.novell.consulting.nl.­accessmanager.tai.Roller¸ provides role provisioning services to WebSphere Application Server (WAS) and WebSphere Portal Server (WPS). HTTP requests from end-user Web browsers are intercepted by Access Manager enriched with supporting information, passed on by Access Manager to WebSphere Application Server and offered to the TAI for validation.

How Does the TAI Module Works?

The TAI module provides role provisioning services to WAS and WPS.The supporting information placed in each request consists of the following fields:

  • Secret Key String: This is used by the TAI to validate that the process has actually gone through Access Manager.

  • User Name: This is the short user name retrieved by Access Manager when the user authenticates.

  • User ID: This is the long user name in LDAP format.The fully qualified distinguished name of the authenticated user within the LDAP store to which Access Manager, WebSphere Application Server, and WebSphere Portal Server are connected.

  • Cache Key: This is the identifier for the user session, as generated by Access Manager.

  • User Roles: This is a list of Access Manager roles for the user.

All fields are fixed strings, stored within the HttpServletRequest as retrievable HTTP headers. When TAI receives a request, it takes the following actions:

  • It verifies that the request contains a secret key value that matches the value specified in the TAI configuration.

  • It prepares for the username, user ID, and cache key to be passed on to WebSphere Application Server, as attributes (WSCREDENTIAL_SECURITYNAME, WSCREDENTIAL_UNIQUEID and WSCREDENTIAL_CACHE_KEY) of a subject within a TAIResult. If a cache key was not provided by Access Manager, the TAI generates one that is based on the current server system time.

  • It filters certain roles out of the list provided by Access Manager, and formulates a full LDAP group DN for each of those. The resulting set of group distinguished names is placed in the TAIResult as the WSCREDENTIAL_GROUPS subject attribute. WebSphere Application Server can perform a lookup in an LDAP store to which it is connected.

  • It filters other roles out of the Access Manager list, constructs another LDAP group DN for each of them, and then establishes the actual membership for the groups by performing LDAP query and update transactions against the LDAP store with which it is configured. With the group objects prepared in this way, WebSphere Portal Server can subsequently query the LDAP store for the members, thus indirectly consuming the role information previously gathered by Access Manager.

Methods

The TAI classes implement five methods:

  • initialize(Properties): Module initialization, based on a configuration that is provided to the TAI as a java.util.Properties set.

  • getType(): Returns the module's Java class name, thereby identifying it to WebSphere Application Server (WAS).

  • get Version(): Returns the module's version number, normally a fixed string.

  • isTargetInterceptor(HttpServletRequest): Establishes whether this particular TAI instance (of wnegotiateValidateandEstablishTrust(HttpServletRequest, HttpServletResponse)negotiateValidateandEstablishTrust(HttpServletRequest, HttpServletResponse) performs the validation of a particular HTTP request, throwing an WebTrustAssociationFailedException on failure.

  • cleanup(): Releases any resources held by the TAI while in its active state.

Configuration Properties

The initialize() method of the TAI currently recognizes the following configuration properties:

  • Secret-Value: Value of the authentication secret placed into requests by Access Manager.

  • Secret-Header: Name of the HTTP request header in which the secret value is placed. As with the other...-header properties, Access Manager. is expected to set the header in question.

  • User-Name Header: Name of the HTTP request header that contains the short user name. It is passed on to WebSphere Application Server as the WSCREDENTIAL_SECURITYNAME attribute.

  • User-ID-Header: Name of the HTTP request header that contains the fully distinguished user name in LDAP format. It is passed on to WebSphere Application Server as the WSCREDENTIAL_UNIQUEID attribute, and used in the arrangement of group membership for role determination by WebSphere Portal Server.

  • Cache-Key-Header: Name of the HTTP request header that contains the cache key for the session. It is initialized by the TAI to the current system time in milliseconds, and expressed as a decimal number when it is unset by Access Manager. It is passed on to WebSphere Application Server as the WSCREDENTIAL_CACHE_KEY attribute.

  • Role-Header: Name of the HTTP request header that lists the user's roles.

  • Role-Separator: Fixed character string that separates individual role names. Used with the role-header, update-roles, and presentation-roles values, all concatenations of role names.

  • Presentation-Roles: Names of the roles that should be presented to WebSphere Application Server (through the WSCREDENTIAL_ GROUPS attribute) as the names of LDAP groups of which the user is a member. Individual presentation role names are separated by the (global) role separator string.

  • Update-Roles: Names of the roles for which the TAI should prepare corresponding LDAP group objects for direct LDAP readout by Websphere Portal Service.

  • Presentation-Container: Distinguished name of the LDAP container that is expected to contain the WebSphere Application Server groups; that is the objects that are merely presented as being groups of which the user is a member.

  • Update-Container: Distinguished name of the LDAP container that is expected to contain the groups for which the TAI should actually manipulate the membership.

  • Update-Connection :URL, in RFC 2255 format, of the LDAP server/store on which group membership should be established for readout by WebSphere Portal Server.Values for this property would typically look like ldap://localhost:1389. The port section of the URL is optional, and only plain-text LDAP is currently supported.

  • Update-User: Distinguished name of the user that logs in to the LDAP group server.

  • Update-Password: Password of the user that logs in to the LDAP group server.

  • Debug-Level: Debug level for the textual output generated by the TAI. It can be Off, Severe, Warning, Info, Config, Fine, Finer, Finest, or All.

Selective Deployment

By selectively leaving out specific configuration properties from the TAI's configuration, the TAI can be configured to refrain from certain activities.

  • When presentation-roles or presentation-container is left unspecified, the TAI does not formulate a WSCREDENTIAL_GROUPS attribute for WebSphere Application Server.

  • When update-user or update-password is left unspecified, the TAI can connect to an LDAP store to manipulate group membership for read-out by WebSphere Portal Server, but does not authenticate (bind) across that connection. Instead, it performs what amounts to an anonymous login. This approach decreases security but improves performance.

  • When update-connection or update-container is left unspecified, the TAI performs no updates at all. For example, there would be no need for the TAI to update groups within an LDAP store if it is deployed in an environment where only WebSphere Application Server (and not WebSphere Portal Server) is used in conjunction with Access Manager.

Update Behavior

One of the TAI's key pieces of functionality is the establishment of group memberships for the currently logged-in user (as identified by Access Manager) within an LDAP store that is queried by WebSphere Portal Server. Here, the LDAP store (normally an instance of eDirectory) is used as a means of indirect communication between Access Manager and the WebSphere Portal Server. Before control is passed to WebSphere Application Server (which in turn calls WebSphere Portal Server), TAI ensures that the group situation in the LDAP store is in line with the role definition provided by Access Manager. Access Manager provides the role definition to TAI through WebSphere Application Server. The role names can be mapped directly to LDAP groups, which give TAI access to a virtual catalog of roles and group objects. Each separate service request (initiated by Access Manager and delivered to TAI by WebSphere Application Server) lists the roles to which Access Manager believes the identified user belongs to. From that actual list of roles, TAI derives whether the user should be a member of each of the groups it knows. It then needs to proceed with implementing the group membership, which can include the following:

  • Adding the user's distinguished name to the member attribute of group objects.

  • Removing the user's distinguished name from the member attribute of group objects.

  • Adding information to or removing information from the groupMembership attribute of the user object.

TAI can replace the previous member and groupMembership values for all objects involved. However, that would require a great number of writes to the LDAP store, operations that (in terms of time) are much more costly than reads. TAI therefore performs a series of queries, one for each group, to determine whether the user is currently a member. If membership is not what it should be, TAI synthesizes a modification of the individual group object. In the reverse direction, a similar optimization is applied, in which updates to the groupMembership back reference attribute are combined into a single joint LDAP modification.

Implementing the Trust Association Interceptor Module

The TAI module is implemented in eDirectory, WebSphere Application Server, and Access Manager.

Configuring eDirectory

Use the following configuration for eDirectory:

  • Place all application groups inside a container. For example, ou=Groups,o=MyOrg

  • Create a wpstaibind user. For example, cn=wpstaibind,ou=Admins,ou=Services,o=MyOrg. This user updates the LDAP groups for the TAI module. Assign the following rights to this user:

    • Create and Modify rights to the ou=Groups,o=MP container.

    • Modify rights to the Membership attribute of all users under the user container.

  • Create a cn=wasadmins,ou=Groups,o=MyOrg group for all WebSphere Application Server administrators.

NOTE:The exact location of WebSphere Portal Server groups can change to a specific application container below the ou=Groups,o=MyOrg container.

Configuring the WebSphere Application Server

Copy the following files to the /usr/WebSphere/AppServer/lib folder:

  • ldap.jar

  • utilities.jar

  • roller.jar

NOTE:The ldap.jar and utilities.jar files are found in the Novell LDAP SDK, located at LDAP Classes for Java. The roller.jar file is available in novell-access-manager.tar.gz (Linux installer).

To configure and enable the TAI module:

  1. Log in to the WebSphere Application Server Admin Console and go to Security / Global Security.

  2. Select Authentication Mechanism > Authentication.

  3. Select LTPA.

  4. Select Trust Association.

  5. Enable the enable trust association check box.

  6. Click Apply to save the changes.

  7. Select Interceptors.

  8. Remove both default TAI modules:

    com.ibm.ws.security.web.TAMTrustAssociationInterceptorPlus
    
    com.ibm.ws.security.web.WebSealTrustAssociationInterceptor
    
  9. Click New.

  10. Specify the following Interceptor class name:

    com.novell.consulting.nl.accessmanager.tai.Roller
    
  11. Select Apply.

  12. Select Custom Properties.

  13. Select New to add the following name/value pairs:

    user-name-header = X-Novell-TAI-UserName

    user-id-header = X-Novell-TAI-UID

    secret-header = X-Novell-TAI-ID

    secret-value = 23870790790732232 (Use whatever value you want)

    cache-key-header = X-Novell-TAI-Cookie

    role-header = X-Novell-TAI-Roles

    role-separator = ;

    presentation-container = (for example, ou=Groups,o=MP)

    update-connection = ldap://<ldapserver DNS name>:389

    update-user = Provide the DN of user in the same format that was created in eDirectory (for example, cn=wpstaibind,ou=Admins,ou=Services,o=MyOrg)

    update-password = <password of wpstaibind user>

    update-container = <Container where groups are to be stored> (for example, ou=Groups,o=MyOrg)

    update-roles = role1;role2;role3;role4; (Roles should be separated by semicolons; do not embed white space in role names)

    presentation-roles = wasadmins

    debug-level = info

  14. Save the changes.

WebSphere Portal Server and WebSphere Application Server need to be restarted before the TAI is enabled. Logging is placed in the SystemOut.log file.

Figure 4-1 TAI Configuration

Mapping WebSphere Application Server Roles to LDAP Groups
  1. From the WebSphere Application Server select System Administration > Console Settings > Console Groups.

  2. Click Add and add the wasadmins group.

  3. Assign the role of Administrator to this group.

Editing Cache Settings
  1. Edit the /usr/WebSphere/PortalServer/wmm/wmm.xml file and change the following:

    • cacheAttributes="true "

    • attributesCacheSize="2000"

    • attributesCacheTimeOut="10"

    • cacheNames="true"

    • namesCacheTimeOut="10”

  2. Stop WebSphere Portal Server and WebSphere Application Server.

  3. Issue a /usr/WebSphere/PortalServer/config/WPSconfig.sh update-properties command to let WebSphere reread the configuration.

  4. Restart WebSphere Portal Server and WebSphere Application Server.

Enabling Logging Levels
  1. From the WebSphere server, select Application Servers > WebSphere_Portal > WebSphere_Portal > Change log level details.

  2. Select com.novell.consulting.

  3. Set the appropriate log level and save changes.

NOTE:If com.novell.consulting is not available, you probably have not yet restarted WebSphere Portal Server. The TAI module is not yet initialized.

All logging is found in the /usr/WebSphere/PortalServer/log/SystemOut.log file.

Figure 4-2 Example Log Configuration

Configuring Access Manager

Access Manager passes all required details to the TAI module via the HTTP header.There are three places where configuration is required:

  • Additions to the Roles policy.

  • Creating an Identity Injection policy for protected WebSphere Portal Server application resources.

  • Assigning the Identity Injection policy to the WebSphere Portal Server application resources.

Configuring the Roles Policy

Because WebSphere Portal Server requires multiple roles, a separate Roles policy named WPS_roles can be created.This policy needs to be assigned to the IDP clusters. Add the following information to the WPS_roles policy.

Create the policies you would require and associate them with the appropriate Authentication contracts.

Configuring the Identity Injection Policy for WebSphere Portal Server Application Resources

Add the following information to the WPS_roles policy, then use the Administration Console to assign the injection policy for the appropriate protected application in Access Manager.