Planning for external security managers

Portal, Express Beta Version 6.1
Operating systems: i5/OS, Linux,Windows

Planning for external security managers

By default, IBM^® WebSphere^® Application Server controls authentication to IBM WebSphere Portal Express and WebSphere Portal Express controls authorization (access control) to resources. You can use an external security manager such as IBM Tivoli^® Access Manager for e-business or Computer Associates eTrust SiteMinder to manage authentication and authorization from a central location.

Note: When setting up security to use an external security manager in a cluster environment and across mixed nodes, there are additional considerations. For example, you should configure your external security manager after completing all other setup tasks, including ensuring that the cluster is functional.

External authentication

Tivoli Access Manager and Computer Associates eTrust SiteMinder provide Trust Association Interceptors (TAI) that are used only as an authentication service. Activate TAI through the WebSphere Application Server Administrative Console. For information about using TAI with WebSphere Application Server, refer to http://www.ibm.com/software/webservers/appserv/was/library/ and theWebSphere Application Server V6 Security Handbook (SG24-6316-00).

Whenever a request attempts to access a secured resource, WebSphere Application Server invokes the TAI, which validates that the request comes from a legitimate third-party authentication proxy and returns the user's authenticated identity to WebSphere Application Server. The TAI should return either a distinguished name (DN) or a short name. WebSphere Application Server performs a registry lookup to verify the distinguished name or convert the short name to a distinguished name before searching for group memberships for that user. If the registry lookup fails, WebSphere Application Server refuses to trust the user. If the registry lookup succeeds, WebSphere Application Server generates a Lightweight Third-Party Authentication (LTPA) token for the user and stores it as a cookie for subsequent authentication during the user's session.

A TAI is not necessary if the third-party authentication proxy provides native WebSphere Application Server identity tokens, such as a LTPA tokens. Currently, only Tivoli Access Manager WebSEAL and Tivoli Access Manager Plugin for Edge Server provide native WebSphere Application Server identity tokens. Consult the WebSEAL Administration Guide for more information about configuring Tivoli Access Manager to provide LTPA tokens. The authentication proxy determines the challenge mechanism, and WebSphere Portal Express relies on the authentication proxy to relay success or failure of the user identifier through the TAI or LTPA token. WebSphere Application Server sees all requests from the TAI as authenticated, but WebSphere Application Server and WebSphere Portal Express still perform a user and group lookup on each request. Even if the authentication proxy has successfully authenticated, WebSphere Application Server and WebSphere Portal Express deny access if they cannot query the user in the registry. For example, it is possible to have a user in an External Security Manager who is not accessible from WebSphere Portal Express because WebSphere Portal Express is configured to one user registry, which may not be the same registry or have the same registry configuration properties as the ESM has.

Custom TAIs

TAIs that allow other custom authentication services to interact with WebSphere Application Server can be written. If you use a security configuration that is different from the ones that are described in this section, provide and implement a TAI to communicate with the authentication proxy.

External authorization

WebSphere Portal Express always determines the permissions that the associates with each role, whether the role is externalized or not. Roles are always associated with a specific resource. Resources can be moved back and forth from internal to external control with the Resource Permissions portlet. Explicit role assignments are preserved when moving in both directions. However, inherited role memberships are blocked for externalized resources. When you externalize access control for a resource, the resource is administered only through the external security manager interface. After externalization, role membership must be assigned and removed using the external security manager. The Resource Permissions portlet can no longer control user access to the resource; however, the Resource Permissions portlet can move the object back to internal control.

Note the following issues:

Private pages cannot be externalized.

When you use the Resource Permissions portlet to externalize or internalize access control for a resource, access control for all of its public child resources moves with it. When you use the XML configuration interface (xmlaccess) to externalize or internalize access control for a resource, access control for public child resources does not change.

After you externalize access control for a resource, use the external security manager to assign users to roles on the resource.

After access control for a resource is externalized, you can use either the Resource Permissions portlet or the XML configuration interface to create additional role types on the resource. For example, suppose you create only the Administrator and Manager role types on the Market News Page. Then you externalize access control for the Market News Page. At this point, use the external security manager to assign users to the Administrator@Market News Page or Manager@Market News Page roles. If you decide that you want to assign users to the Editor@Market News Page role, which has not yet been externalized, follow these steps:
1. Use the Resource Permissions portlet to create the Editor role type for the Market News Page.
2. Use the external security manager to assign users to the Editor@Market News Page role by editing the ACL.
Remember that WebSphere Portal Express still determines the permissions that are associated with the externalized Editor role type.

Externalizing the access control for a resource severs any access control inheritance from internally controlled parent resources. The user who is performing the externalization automatically receives the Administrator role on the parent resource of the externalized resource tree (if using the Resource Permissions portlet) or the resource (if using the XML configuration interface).

The decision to use an external security manager must be made with the understanding that the external security manager software's ACL semantics override WebSphere Portal Express semantics. For example, if you use Tivoli Access Manager to grant anonymous membership on a role for an externally controlled portlet, set the ACL for that portlet to include the Tivoli Access Manager unauthenticated user group.

Note: If you use Tivoli Access Manager for authorization, also use it for authentication. Using Tivoli Access Manager to perform only authorization is not supported.

Planning considerations for WebSEAL junctions

A junction is an HTTP or HTTPS connection between a front-end WebSEAL server and a back-end Web application server. A junction acts as a single point of access into a Web Application Network. WebSEAL performs authentication checks on all requests for resources before passing those requests across a junction to the back-end server.

In the configuration described here, the WebSEAL component of Tivoli Access Manager handles the user authentication, and a Trust Association Interceptor (TAI) is used by WebSphere Application Server and WebSphere Portal Express to accept the identity of the user as asserted by WebSEAL.

To properly secure the WebSphere Application Server and WebSphere Portal Express system against an attack, the TAI must still authenticate the WebSEAL server, so that only requests that are legitimately presented through that WebSEAL server are accepted. You have a choice of different ways to configure this authentication between WebSEAL and the TAI in WebSphere Application Server, depending on how much effort and performance you wish to put into securing your network. The decisions you make will determine how you set up the junctions between the WebSEAL server and WebSphere Portal Express.Note: By default, the XML configuration interface cannot access WebSphere Portal Express through a WebSEAL junction. To enable the XML configuration interface to access WebSphere Portal Express through a WebSEAL junction, use Tivoli Access Manager to define the configuration URL (/wps/config) within the junction as unprotected. Refer to the WebSEAL documentation for specific instructions about defining separate URLs within the junction and assigning separate ACLs to these URLs. After the configuration URL is defined as unprotected, only WebSphere Portal Express enforces access control to this URL. Other resources that are protected within the WebSEAL junction (for example, the wps/myportal URL) are still protected by WebSEAL.

Nonencrypted junction using Basic Authentication

The identity of the user must be passed to the TAI in a header called iv-user, which is inserted by WebSEAL into the request that is sent from WebSEAL to the WebSphere Application Server and the WebSphere Portal Express servers. The junction creation option to set this up is -c iv-user. While WebSEAL can be configured to pass the user identity in other ways, the iv-user header is the only one that is supported by the TAI.

Advanced junction configurations

For more details and options about how to configure junctions between WebSEAL with WebSphere Application Server and WebSphere Portal Express, including other options for specifying the WebSEAL server identity, refer to the WebSEAL Administration Guide and to the documentation for the HTTP Server that you are using with WebSphere Application Server.

The junctions between WebSEAL and WebSphere Application Server and WebSphere Portal Express can be configured to be encrypted or not. Encrypted junctions enhance security by making sure that no one can eavesdrop on information that is flowing between WebSEAL, WebSphere Application Server, and WebSphere Portal Express. However, encrypted junctions require additional administration to move the necessary signing certificates between the systems, and also have a performance cost. If you are not comfortable that your network between the firewalls is secure against unauthorized access and observation, you should use encrypted junctions between WebSEAL and WebSphere Application Server/WebSphere Portal Express. If you are comfortable that your network is secure against unauthorized access and observation, especially for traffic across an inner firewall, you can use unencrypted junctions between WebSEAL and WebSphere Application Server/WebSphere Portal Express.

Set up the WebSEAL-WebSphere Application Server/WebSphere Portal Express junction over SSL requires that you configure WebSphere Application Server and the HTTP server that is used by WebSphere Application Server to accept inbound SSL traffic and route this traffic correctly to WebSphere Application Server and WebSphere Portal Express. This process includes importing the necessary signing certificates into at least the WebSEAL certificate keystore, and possibly also the HTTP server certificate keystore.

If you choose to use encrypted junctions between WebSEAL and WebSphere Application Server and WebSphere Portal Express, you can also choose to have WebSEAL identify and authenticate itself to WebSphere Application Server and the TAI using its own client-side certificate. In this case, it is possible to configure the TAI to not do any further validation of the WebSEAL server, relying on the mutual SSL connection to supply a trustable identity for the WebSEAL server.

If you choose not to use client-side certificates to identify the WebSEAL server, or if you choose not to use an SSL junction, you can identify the WebSEAL server to the TAI using a Basic Authentication (BA) header. In this case a password will be placed into the BA header, and also configured into the TAI. This represents a "shared secret" that only the TAI and the WebSEAL server know, which allows the TAI to trust that it really is the WebSEAL server that is asserting the user's identity, and the TAI can trust it. In this case, using an SSL junction will provide additional security by protecting this BA header from observation, but the TAI will still rely on the BA header for identifying the WebSEAL server.

To set up the junction to use the Basic Authentication header to identify the WebSEAL server, use the -b supply option on the junction creation command. This will cause WebSEAL to build the BA header using the user's user ID (which is ignored by the TAI, in favor of the iv-user header) and the password that is configured into WebSEAL from the webseald-instance.conf file, on the basicauth-dummy-passwd property. The password in the webseald-instance.conf file must match the password for the ID that is specified on the com.ibm.websphere.security.webseal.loginid property of the TAI startup parameters in the WebSphere Application Server Administrative Console. For example, if you specify com.ibm.websphere.security.webseal.loginid=mistered on the TAI startup parameters, and the password for mistered is wilbur, then specify wilbur on the basicauth-dummy-passwd property in webseald-instance.conf on the WebSEAL server.

Parent topic: Security and authentication considerations

Library | Support | Terms of use |