WebSphere JAX-WS Cross-Cell authentication

Question

We want to build a front-end web application to consume the WPS’ HumanTask API using JAX-WS. This web application should be able to query current tasks for a specific user, claim tasks not claimed previously by any other user, complete tasks and so on. This web application will be deployed on a WAS 7.0 on a different cell than the one providing the HumanTask service (Currently we are using another WPS instance as the WAS but eventually it will be a simple WAS without WPS features). We synchronized LTPA generation keys by means of following steps:

1. Login to one cell
2. Go to "Security" > "Global Security". Under "Authentication" click on "LTPA"
3. Under "Cross-cell single sign on"
   1. Establish a password
   2. Confirm the password
   3. Input the file name into which the LTPA keys will be exported
   4. Click on "Export keys"
4. Log out
5. Copy the generated file to the other server
6. Login to the other cell
7. Go to "Security" > "Global Security". Under "Authentication" click on "LTPA"
8. Under "Cross-cell single sign on"
   1. Input previous password
   2. Confirm password
   3. Input the file name with the exported LTPA keys
   4. Click on "Import keys"
9. Restart server

We developed a simple web application with GWT as a proof of concept with a simple UI and a web service client which consumes the HumanTask JAX-WS service. This web application is protected behind a Siteminder authenticator (when first entering web application Siteminder agent redirects to a web form asking for credentials). Web service client has been developed following JAX-WS standards, no additional dependencies have been added, we rely on WebSphere JAX-WS implementation (Apache Axis2). Once deployed we tested two scenarios without luck:

Scenario A:

• By default WPS’ HumanTask service provider is attached to policy set “BPC Web Service” with default policy set binding and policy set sharing disabled.
• We configure our HumanTask service client to use same policy set as service provider.

• Log in to custom web application. When trying to query current tasks we get following exception:

  com.ibm.wsspi.wssecurity.core.SoapSecurityException: security.wssecurity.WSSContextImpl.s02: com.ibm.websphere.security.WSSecurityException: Exception org.apache.axis2.AxisFault: CWWSS6521E: The Login failed because of an exception: javax.security.auth.login.LoginException: Login Failure: all modules ignored ocurred while running action: com.ibm.ws.wssecurity.handler.WSSecurityGeneratorHandler$2@6fef6fef
  

No error message at service provider side.

Scenario B:

• Change WPS’ HumanTask service provider configuration enabling policy set sharing through HTTP GET. This way service provider WSDL contains information about the policy set.
• Change policy set configuration at service client to obtain policy set from provider using HTTP GET.

• Log in to custom web application. When trying to query current tasks we get following exception:

  javax.xml.ws.soap.SOAPFaultException: security.wssecurity.WSSContextImpl.s02: com.ibm.websphere.security.WSSecurityException: Exception org.apache.axis2.AxisFault: CWWSS6521E: The Login failed because of an exception: javax.security.auth.login.LoginException: Login module com.ibm.ws.wssecurity.wssapi.token.impl.UNTConsumeLoginModule login() method returned false ocurred while running action: com.ibm.ws.wssecurity.handler.WSSecurityConsumerHandler$1@54a054a0
  

Before reaching the point where previous exception is reported we see following warning at service client logs:

CWWSS7053W: No web services security custom bindings were found. Default bindings will be used.

At service provider logs we can see following error:

CWWSS5514E: An exception while processing WS-Security message.

And a set of FFDCs are generated reporting the same exception we got at service client side.

Someone who could help us would be great!

Answer 1

We had the same problem but managed to solve it via the following steps. Essentially, you need to change the default policy set applied to the HTM JAXWS API (the default is really just an example) and use a custom provider binding which is able to extract the identity contained within the LTPA token via a "Caller". Steps below:

Create Custom Policy Set Bindings

1) Click "Services" > "Policy Sets" > "General provider policy set bindings" 2) Select the "Provider sample" binding and click "Copy..." 3) Enter the name as "LTPA Authenticated Caller" and click OK 4) Click on "LTPA Authenticated Caller" in the list of bindings 5) Click on "WS-Security", then "Caller" 6) Click "New" and enter the following details (leave other fields blank) Name: auth_ltpa Caller identity local part: LTPAv2 Caller identity namespace URI: http://www.ibm.com/websphere/appserver/tokentype Click OK

Assign Policy Set and Bindings

1) Expand "Services", click "Service providers" 2) Click on "HTMJAXWSService" 3) Click the checkbox to select the HTMJAXWSService Service in the Policy Set Attachments list, then click on "LTPA WSSecurity default" in the Attach Policy Set drop down list 4) Click the checkbox to select the HTMJAXWSService Service in the Policy Set Attachments list, then click on "LTPA Authenticated Caller" in the Assign Binding drop down list 5) Save all changes to the master configuration.

Assign Policy Set and Bindings

1) Expand "Services", click "Service clients" 2) Click on the "HTMJAXWSService" link where the "Deployed asset" column matches the module containing the client you wish to configure 3) Click the checkbox to select the HTMJAXWSService Service in the Policy Set Attachments list, then click on "LTPA WSSecurity default" in the Attach Policy Set drop down list. Ensure that this setting is inherited by all child levels (i.e. the port, and all methods) 4) Click the checkbox to select the HTMJAXWSService Service in the Policy Set Attachments list, then click on "Default" in the Assign Binding drop down list 5) Save all changes to the master configuration

Conclusion

It should now be possible to call from your client through to the HTM API using LTPA authentication. In order to do this, your client application will need to be configured to either require authentication or provide authentication for unauthenticated URLs (the latter would be appropriate for applications which are expecting the SiteMinder TAI to pre-populate an authenticated user identity).

Hope this helps!