• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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:
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.ws.security/wss4j/1.5.4/org/apache/ws/security/processor/UsernameTokenProcessor.java

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.
 
Guy Cooke
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

Guy.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic