Plan for external security managers

 

+

Search Tips   |   Advanced Search

 

By default, IBM WebSphere Application Server controls authentication to IBM WebSphere Portal and WebSphere Portal controls authorization (access control) to resources. Use an external security manager such as...

• IBM Tivoli Access Manager for e-business
• eTrust SiteMinder

...to manage authentication and authorization from a central location.

For cluster environments and across mixed nodes 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. Activate TAI through the WAS Administrative Console.

For information about using TAI with WAS, see WAS V6 Security Handbook (SG24-6316-00).

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 (DN) or a short name.

WAS performs a registry lookup to verify the DN or convert the short name to a DN 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. The following proxies provide native WAS identity tokens....

• TAM WebSEAL
• TAM Plugin for Edge Server

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 always determines the permissions that 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 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, to create additional role types on the resource, use either...
  • Resource Permissions portlet
  • XML configuration interface

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

  • Administrator@Market News Page
  • Manager@Market News Page roles

  To assign users to...

  • Editor@Market News Page

  ...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 role...
     Editor@Market News Page role

     ...by editing the access control list.

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

  • externalized resource tree (Resource Permissions portlet)
  • resource (xmlaccess)

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

• front-end WebSEAL server
• back-end Web application server

...acting 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, handling the user authentication.

A Trust Association Interceptor used by WebSphere Portal accepts the identity of the user. The TAI authenticates the WebSEAL server, so that only requests that are legitimately presented through that WebSEAL server are accepted.

xmlaccess

By default xmlaccess cannot access WebSphere Portal through a WebSEAL junction. To enable access to WebSphere Portal through a WebSEAL junction, use TAM utilities to define the folllowing configuration URL within the junction as unprotected...

/wps/config

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

The configuration URL...

wps/myportal URL

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

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

 

Encrypting junctions

Encrypted junctions require...

• Additional administration to move the necessary signing certificates between the systems
• Have a performance cost

Setting up the WebSEAL <--> Portal junction over SSL requires that you...

• Configure WAS and the HTTP server used by WAS to accept inbound SSL traffic
• Route this traffic correctly to WAS and WebSphere Portal

This process includes importing the necessary signing certificates into...

• WebSEAL certificate keystore
• HTTP server certificate keystore (Optional)

WebSEAL can identify and authenticate itself to WAS and the TAI using its own client-side certificate, in which 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. A password will be...

• placed into the BA header
• configured into the TAI

...representing a "shared secret" that only the TAI and the WebSEAL server know, allowing 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 option...

-b supply

...on the junction creation command, which will cause WebSEAL to build the BA header using the user's user ID (ignored by the TAI, in favor of the iv-user header).

The password configured into WebSEAL from webseald-instance.conf on the property...

basicauth-dummy-passwd

...in webseald-instance.conf must match the password for the ID specified on the property...

com.ibm.websphere.security.webseal.loginid

...of the TAI startup parameters in the WAS 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 for...

basicauth-dummy-passwd

...in webseald-instance.conf on the WebSEAL server.

 

Parent topic

Security and authentication considerations