External authentication

 

+
Search Tips   |   Advanced Search

 

By default, WebSphere Portal relies on WebSphere Application Server for authentication. We can also configure a third-party authentication proxy server, such as IBM Tivoli Access Manager for e-business WebSEAL, to perform authentication for WebSphere Portal. WAS typically uses a Trust Association Interceptor (TAI) to trust the external authentication proxy.

External authentication is anything in front of WAS that does the authentication. Login dialog conducted by front end security.

May use Portal to serve up the login page, but Portal no longer handles the login form submission.

Front end asserts already-authenticated end user identity to WAS. Trust Association Interceptor (TAI) architecture. TAM has other options (LTPA junctions).

TAI is a WAS feature, not a Portal feature. Documented in the WAS InfoCenter

Portal has no idea about presence or absence of TAI, or how WAS gets the user identity. IBM only provides one (1) TAI that for TAM/WebSEAL. *ALL OTHER SECURITY VENDORS MUST PROVIDE THEIR OWN TAI!!!!*

Front end/TAI, WAS, and WP should all use the same user registry. It is possible to map between different registries for front end vs. WAS/WP but this is complex, leads to hard-to-debug problems TAI can assert a security shortname that WAS will look up using search.

TAI++ can set end user identity, bypassing lookup Portal still needs to be able to look up profile info for that user

TAM and Computer Associates eTrust SiteMinder provide TAIs that are used only as an authentication service for WebSphere Portal. TAIs must be activated through the WAS Administrative Console. WebSphere Portal now provides the capability to automatically activate TAIs for TAM and eTrust SiteMinder.

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 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 an 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 Plugin 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 (ESM) 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's.

 

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. Refer to the WAS information center and to the WAS V6 Security Handbook (SG24-6316-00) for additional information about creating custom TAIs.

 

Verify that the TAI is working properly

After completing the configuration to enable External Authentication, follow these steps to verify TAI operation.

  1. Use this address to test the TAI from a Web browser:

    https://WebSEAL_hostname:WebSEAL_port/junction/wps/myportal

    ...or...

    http://SM_agent_hostname:SM_agent_port/wps/myportal

    WebSEAL or eTrust SiteMinder should challenge us to authenticate. After you log in you should be directed to the secure and personalized myportal page. If you are directed to the portal login screen at wps/portal/.scr/Login or the public page, there is a problem with the TAI configuration.

    For TAM only: Test the TAI by using TAM to add a new user...

    pdadmin> user create user_name user_dn cn sn pwd
    pdadmin> user modify user_name account-valid yes

    Verify that WebSphere Portal is running, open the browser, and go directly to...

    https://WebSEAL_hostname/junction/wps/myportal
    WebSEAL will prompt for the new user ID and password. You should be taken to a new authenticated user page as the specified user.

  2. Proceed to Change the login and logout pages.

 

Related information

 

Parent Topic

External security managers