JAAS and JBossWS

[cbax007]

I'm using JBoss-4.0.4.GA and I was just wondering why passing the security information in the incoming soap message header like so:

<env:Header>
 <jbws:username actor='http://webservice.jboss.com/ws4ee/login' xmlns:jbws='http://webservice.jboss.com/ws4ee'>report</jbws:username>
 <jbws:password actor='http://webservice.jboss.com/ws4ee/login' xmlns:jbws='http://webservice.jboss.com/ws4ee'>report</jbws:password>
</env:Header>

no longer causes a JAAS login on the back end. How can I get this to work again as it did in JBoss-4.0.3.SP1? I don't want to use BASIC auth; I want to be able to pass this information in the header and have it cause a JAAS login. My endpoint is a POJO and is deployed in a WAR. What files do I need to touch up (i.e. web.xml, jboss-web.xml, etc...) to make this happen?

[cbax007]

Just a little more info on this. In JBoss-4.0.3.SP1, the login was accomplished with org.jboss.webservice.handler.ServerLoginHandler which was part of the standard request flow. All that class did was to set the principal and credential via SecurityAssociation (not actually logging in via JAAS). Later in the flow, when my EJB was called after, that's when the login would occur using the info on set onto SecurityAssociation. Is there any way to make this work again in JBoss-4.0.4.GA? Should I be trying to accomplish this via the UserNameToken aspect of WS-Security? If I put that standard info into the header, will it have the same affect as the older style did in JBoss-4.0.3.SP1? Do I have to implement my own custom handler to support this?

[thomas.diesler]

This was identified as an security issue (which relayed the callers username/password to an arbitrary callee) and removed without replacement.

I suggest you implement this behaviour at application level in a propriatary way using the jboss SecurityAssociation or in a portable way using ws-security

[cbax007]

I have solved this problem using client and server side handlers. The client handler creates a UsernameToken object and uses the getElement() method and appends that into the outgoing message. The server side handler grabs that token (again using UsernameToken) and sets the Principal and Credential on SecurityAssociation just like the old handler.

This seems to work okay in almost all situations. The only issue I can see is if my POJO endpoint has to look up and call a Session Bean using the JBoss Asynch Proxy functionality. Some of my webservice calls can be asynch because they don't require a response. So in these cases, I lookup the Session Bean and then get the Asynch Proxy for it and make the call on that instead of the looked up EJB. Some of these EJBs call other secure EJBs and when this happens using this asynch functionality, I get some security based errors, as if I no longer have a security association. If I tweak my code to do it synchronously, the errors stop.

What I want to know is if there is some standard handler in your server side chain that strips security credentials when the webservice call completes? That could explain why it works in synch mode but not in asynch. In asynch mode, my EJB calls are still trying to run after the webservice call completes (and possibly clears security info from current thread).