Guy Cooke

Praveen,

I see you have been told here that this is not possible to share sessions, but this is not entirely correct.

What you are asking for, it sounds like, is "session replication." It is possible, but the way you do it depends on your application server and your application.

The idea of storing session state information in the database is perfectly acceptable. You may be able to find existing implementations of this for your platform.

Other strategies usually involve "in memory session replication" (another buzz-phrase you can search for). This may be supported by your application container/application server and you just need to set it up. Again, this will be different between application servers. You will need to research the options for yours.

If you run out of options and have to make your own, you might want to start by looking at the javax.servlet.http.HttpSessionListener interface. You might use this to instantiate and destroy sessions in your database, if you want to go that way. It would be easy to write code to load and store the session information you are interested in retaining in the database at the beginning and end of each request. In this case you would have to be able to modify APP1 and APP2.

Good luck!

Guy.

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.

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.

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:
<parameter name="InflowSecurity"> <action> <items>Timestamp UsernameToken</items> <passwordCallbackClass> app.services.security.WebServiceTokenHandler </passwordCallbackClass> </action> </parameter>

When the WCF client calls the service, the security header is like this:
<s:Header> <o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"> <u:Timestamp u:Id="_0"> <u:Created>2011-03-30T17:43:51.953Z</u:Created> <u:Expires>2011-03-30T17:48:51.953Z</u:Expires> </u:Timestamp> <o:UsernameToken u:Id="uuid-b485373e-78a9-4440-aa44-9c3c9740eed0-1"> <o:Username>MyAppId</o:Username> <o:Password o:Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">MyAppPassword</o:Password> </o:UsernameToken> </o:Security> </s:Header>

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:
133 if (cb == null) { 134 throw new WSSecurityException(WSSecurityException.FAILURE, "noCallback"); 135 } else if (!WSConstants.PASSWORD_TEXT.equals(pwType) && !handleCustomPasswordTypes) { 136 if (log.isDebugEnabled()) { 137 log.debug("Authentication failed as handleCustomUsernameTokenTypes is false"); 138 } 139 throw new WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION); 140 }

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.