WebSphere Portal protected page not displayed after authenticating to WebSEAL

Technote (troubleshooting)


After setting up Tivoli® Access Manager to handle authentication for WebSphere® Portal, you test the login by doing the following:

1. Enter the following URL in the browser:

2. Submit your login credentials using the WebSEAL login page.

Instead of being taken to the WebSphere Portal personalized page for your user ID, you are prompted with the login page for WebSphere Portal or you are taken to the anonymous welcome page.

Resolving the problem

This issue has occurred in seven separate scenarios and required a different solution in each case:

1. To troubleshoot the first environment, if you collect a trace of the Trust Association Interceptor (TAI), you will see the following in the trace.log:

[date/time] 19b43cad WebSealTrustA d Host and port:
MYTESTSERVER:80 is not trusted.    

Also, in the TAI initialization of the trace.log, you can see which hosts and ports had been set as trusted:

[date/time]  c903ca2 WebSealTrustA d WebTAInterceptor:
Added source =mytestserver.acme.com:80                          
[date/time]  c903ca2 WebSealTrustA d WebTAInterceptor:
Added source = mytestserver.acme.com:443                        
[date/time]  c903ca2 WebSealTrustA d WebTAInterceptor:
Added source = mytestserver:80                                      
[date/time]  c903ca2 WebSealTrustA d WebTAInterceptor:
Added source = mytestserver:443                                      

In other words, the hostname setting is case-specific. Given this information, the hostname "MYTESTSERVER" must be added as a value to the custom property "com.ibm.websphere.security.webseal.hostnames" using the WebSphere Application Server Administrative Console. The location of the custom property is:
LTPA->Trust Association->Interceptors->
com.ibm.ws.security.web.WebSealTrustAssociationInterceptor->Custom Properties          

After making the change, save it using the administrative console, stop the server1 application server, and restart the WebSphere_Portal application server.

2. To troubleshoot the second environment, review the WebSphere Portal configuration files. When viewing the following file, it may contain properties that were not set correctly for a secure portal: <wp_home>/shared/app/config/services/ConfigService.properties

For example, the following property and value:
was.security.enabled=false (should be "true" on a secure portal)

Confirm that the values in the <wp_home>/config/wpconfig.properties are correct. If you know that WebSphere Global Security was enabled correctly in WebSphere Application Server, run the following configuration task on the portal server and then restart all servers:

<wp_home>/config/> wpsconfig secure-portal-ldap

This task updates the portal configuration files with the correct values.

3. In this third scenario, the customer was actually using a WebSEAL junction that used LTPA rather than the TAI. The login form for WebSphere Portal was being displayed because the LtpaToken set by WebSEAL did not match the LtpaToken set in WebSphere Application Server. To address the issue, the customer re-exported the LTPA keys from WebSphere Application Server and imported them into Tivoli Access Manager.

4. For the fourth scenario, the customer provided a wps log, which displayed the following:

    2005.11.30 16:18:47.517 E com.ibm.wps.engine.Servlet handleException
    EJPEJ0069E: URL parsing problem, URL= http://aecpl001/wps/myportal.

    2005.11.30 16:18:47.517 l com.ibm.wps.engine.Servlet handleException    
    Servlet.Engine.Transports : 0                                            
      An exception occurred while processing the request. - StackTrace      
    n: EJPSD0005E: Portal JAAS Login Failed for user with DN                
    . . . .                                                                  
    Caused by: javax.security.auth.login.LoginException: Error:              
    javax.security.auth.callback.NameCallback@2aaf2986 not available to      
    garner authentication information from the user.                        
     at com.tivoli.mts.PDLoginModule.login(PDLoginModule.java:97  

IBM Support checked the customer's <was_home>/config/cells/<cellname>/security.xml and noticed that login modules were missing including:
     <loginModules xmi:id="JAASLoginModule_1118776945510" moduleClassName="com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy" authenticationStrategy="REQUIRED">
            <options xmi:id="Property_1118776949846" name="delegate" value="com.tivoli.mts.PDLoginModule"/>
            <options xmi:id="Property_1118776951308" name="configURLName" value="file:C:/WebSphere/AppServer/java/jre/PdPerm.properties "/>
            <options xmi:id="Property_1135173450126" name="debug" value="true" required="false"/>

Support found out that customer had manually configured WebSphere Portal and Tivoli Access Manager instead of running the configuration task. Customer ran enable-tam-all, and then the issue no longer existed because the task actually populates the appropriate login modules as needed.

5. After authenticating to WebSEAL, a Web user is redirected to the Portal anonymous welcome page instead of the Portal authenticated page. This behaviour started occurring only after an upgrade to WebSphere Portal and WebSphere Application Server

To address the issue for this fifth scenario, the customer installed PK21624.

6. The sixth scenario of getting the Portal login page occurs when a user uses the anonymous URL to test the login: https:// :WebSEAL_port/junction/wps/portal

Basically, after WebSEAL authenticates the user, it redirects the request to WebSphere Portal. However, once the portal server sees the request for /portal, it automatically logs out the customer. Thus, the user is then presented w/ the login page. Therefore, as documented in the WebSphere Portal Infocenter, the protected URL /myportal should be used to test that the integration is working successfully: https:// :WebSEAL_port/junction/wps/myportal

7) The seventh scenario resulted in the following exception in SystemOut.log:

date/time 4f463c22 WMM Trace Log e com.ibm.ws.wmm.ldap.LdapRepositoryImpl Attributes getAttributes(String name, String[] attrIds) The following exception was logged
                                 com.ibm.websphere.wmm.exception.MemberNotFoundException: LDAP DN "cn=john_doe,dc=ibm,dc=com" is not found.
at com.ibm.ws.wmm.ldap.LdapRepositoryImpl.getAttributes(LdapRepositoryImpl.java:363)

In this scenario, the customer had WebSEAL and WebSphere Portal pointing to different LDAP servers. While these servers did have the same user IDs, they did not contain the same DN for the users. This caused a problem because the customer was using com.ibm.ws.security.web.TAMTrustAssociationInterceptorPlus (TAI ++) to handle the requests. This results in the HTTP header "iv-creds" containing a reference to the LDAP used by WebSEAL, and thus you'll get a Subject similar to:

Principal: cn=john_doe,dc=ibm,dc=com
Principal: PDPrincipal:  john_doe
Principal: portalLDAP:389/john_doe

This means that Portal will then attempt to use this full DN to search the LDAP it is configured to, and since the DN does not match, it returns the above error. To resolve the issue, you can:

A) Use TAI (com.ibm.ws.security.web.WebSealTrustAssociationInterceptor) instead of TAI ++. It should just pass the username and let WebSphere Portal handle the lookup in the LDAP by username.

B) Make the DNs identical in the two LDAP directories

C) Use the same directory for both WebSEAL and WebSphere Portal.

Rate this page:

(0 users)Average rating

Add comments

Document information

More support for:

WebSphere Portal End of Support Products

Software version:

5.0.2, 5.1, 6.0

Operating system(s):

AIX, Linux, Solaris, Windows, i5/OS

Software edition:

Enable, Express, Extend, Server

Reference #:


Modified date:


Translate my page

Machine Translation

Content navigation