Planning for external security managers



Search Tips   |   Advanced Search


By default, IBM WAS controls authentication to WebSphere Portal and WebSphere Portal controls authorization (access control) to resources. You can use an external security manager such as IBM Tivoli Access Manager or eTrust SiteMinder to manage authentication and authorization from a central location.

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

TAM and eTrust SiteMinder provide Trust Association Interceptors (TAI) that are used only as an authentication service. Such TAIs can be configured via the Portal configuration tasks.

For example, the enable-tam-tai task sets up the TAM TAI with the relevant properties. The TAM TAI requires that the TAM authorization server be available for successful single sign-on. For information about using TAI with WAS, refer to...

Whenever a request attempts to access a secured resource, WAS invokes the TAI, which validates that the request comes from a legitimate third-party authentication proxy and returns the user's authenticated identity to WAS. The TAI should return either a distinguished name or a short name. WAS 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, WAS refuses to trust the user. If the registry lookup succeeds, WAS generates a 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 WAS identity tokens, such as a LTPA tokens. Currently, only TAM WebSEAL and TAM plug-in for Edge Server provide native WAS identity tokens. Consult the WebSEAL Administration Guide for more information about configuring TAM to provide LTPA tokens. The authentication proxy determines the challenge mechanism, and WebSphere Portal relies on the authentication proxy to relay success or failure of the user identifier through the TAI or LTPA token. WAS sees all requests from the TAI as authenticated, but WAS and WebSphere Portal still perform a user and group lookup on each request. Even if the authentication proxy has successfully authenticated, WAS and WebSphere Portal 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 because WebSphere Portal 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 WAS 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 determines the permissions associated 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 externalizing the resource, 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.

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...


...roles. If you decide that you want to assign users to the...

...role, which has not yet been externalized...

  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 still determines the permissions that are associated with the externalized Editor role type.

If a user inherits access to a resource from a parent resource, the user will lose the inherited access when the resource is externalized. If the user needs access to that resource, assign access through the external security manager.

The user, who externalizes the resource, 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 semantics.

For example, if you use TAM to grant anonymous membership on a role for an externally controlled portlet, set the ACL for that portlet to include the TAM unauthenticated user group.

If you use TAM for authorization, also use it for authentication. Using TAM 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 appserver. 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 TAM handles the user authentication, and a Trust Association Interceptor (TAI) is used by WAS and WebSphere Portal to accept the identity of the user as asserted by WebSEAL.

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 WAS, 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.

By default, the XML configuration interface cannot access WebSphere Portal through a WebSEAL junction. To enable the XML configuration interface to access WebSphere Portal through a WebSEAL junction, use TAM to define the configuration URL...

...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 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 WAS and the WebSphere Portal servers. The junction creation option to set this up is...

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.

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 file webseald-instance.conf must match the password for the ID specified on the property...

...of the TAI startup parameters in the admin console.

For example, if you specify...

...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.

Advanced junction configurations

For more details and options about how to configure junctions between WebSEAL with WAS and WebSphere Portal, 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 WAS.

Set up the WebSEAL-WAS-Portal junction over SSL

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

The junctions between WebSEAL and WAS and WebSphere Portal 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, WAS, and WebSphere Portal. 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, use encrypted junctions between WebSEAL and WAS/WebSphere Portal.

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 WAS/WebSphere Portal.

If you choose to use encrypted junctions between WebSEAL and WAS and WebSphere Portal, you can also choose to have WebSEAL identify and authenticate itself to WAS 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.

Parent topic:

Security and authentication