jQuery in Action, 2nd edition*
The moose likes Web Services and the fly likes Axis2/Rampart fails auth from WCF client, never calls password callback handler Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Web Services
Bookmark "Axis2/Rampart fails auth from WCF client, never calls password callback handler" Watch "Axis2/Rampart fails auth from WCF client, never calls password callback handler" New topic

Axis2/Rampart fails auth from WCF client, never calls password callback handler

Guy Cooke

Joined: Mar 30, 2011
Posts: 4
Much obliged for any help I can get on this one. I feel like I must be missing something stupid:

I have an Axis2 (1.5.1) web service being invoked by a WCF (.NET 3.5) client application.

The web service works fine without any authentication/inflow security configuration, but I have been asked to implement authentication using a security header.

I am using this kind of configuration in services.xml:

When the WCF client calls the service, the security header is like this:

Which looks fine to me (what do I know?), but Axis2/Rampart fails to authenticate the request:

org.apache.axis2.engine.AxisEngine receive WSDoAllReceiver: security processing failed
org.apache.axis2.AxisFault: WSDoAllReceiver: security processing failed
at org.apache.rampart.handler.WSDoAllReceiver.processBasic(WSDoAllReceiver.java:214)
at org.apache.rampart.handler.WSDoAllReceiver.processMessage(WSDoAllReceiver.java:86)
at org.apache.rampart.handler.WSDoAllHandler.invoke(WSDoAllHandler.java:72)
at org.apache.axis2.engine.Phase.invoke(Phase.java:318)
Caused by: org.apache.ws.security.WSSecurityException: The security token could not be authenticated or authorized
at org.apache.ws.security.processor.UsernameTokenProcessor.handleUsernameToken(UsernameTokenProcessor.java:139)
at org.apache.ws.security.processor.UsernameTokenProcessor.handleToken(UsernameTokenProcessor.java:53)
at org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:311)
at org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:228)
at org.apache.rampart.handler.WSDoAllReceiver.processBasic(WSDoAllReceiver.java:211)
... 30 more

I have a log message in my callback handler's static initializer that tells me that the class was loaded, but the handle method is never called.

This is the code I believe maps to my implementation of UsernameTokenProcessor:

There, I found that this exception is coming up here:

But, as you can see above, WSConstants.PASSWORD_TEXT matches what I am getting in the request (it is "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText") so I am at a loss for why this might be happening.

Thanks for any insights you can provide.

Guy Cooke

Joined: Mar 30, 2011
Posts: 4
It's unfortunate that I was not able to get any help on this one, so I'm back to help myself.

Hi, Guy.

Your problem is that your application server (WAS 6.1) has a default installation of Axis2 to provide "out-of-the-box" web service support, and you are not using it. This is possibly because there is something wrong with or you don't like the Axis2 version that comes with WAS for some reason, or because you don't know it is there. Your problem is that your application server is loading Axis2 components from the out-of-the-box version and then probably some additional components from your application's libs/jars.

Basically, you are probably working with some sort of dirty, Frankenstein version of Axis2 and that is leading to problems. Make sure all of your Axis2 resources are coming from where you expect them, and you should be fine.
Guy Cooke

Joined: Mar 30, 2011
Posts: 4
Thanks for your help, Guy.

It turns out the application was configured to do class loading parent- or container- first, so the server would load the WAS version of Axis2 before the version in my application. The easy fix would be to switch this to application-first class loading, which is the default.

It turns out I can't do this because another 3rd-party component in the application requires the container-first class loading scheme, and it breaks if I switch to application-first class loading.

I am not happy about it, but to resolve this, I took the Axis2 classes and resources I needed and added them to my class tree (WEB-INF/classes) and documented this everywhere I could think to. This works because I understand the load order is now (with parent-first or container-first class loading):

1. WEB-INF/classes
2. container/application server classpath
3. WEB-INF/lib/*.jar

So, fixed, but gross.

Thanks again, Guy.

With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
subject: Axis2/Rampart fails auth from WCF client, never calls password callback handler
Similar Threads
Custom UsernameToken?
Issue with using the Axis2 JAX-WS Client using Rampart
Axis2 and mustUnderstand
problem with Subject Key Identifier
WCF, Rampart, ADFS2 and SAML Interop issue