You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by cmarshall <cm...@courseadvisor.com> on 2009/05/30 22:26:29 UTC

JAAS in Server Password Callback?

The documentation for using WS-Security with CXF describes creating and
configuring a CallbackHandler that is supposed to produce the password for a
user so the calling routines can verify that the password is correct.  JAAS
would expect that both the username and password would be supplied to it. Is
there a way to configure the WSS4JInInterceptor to pass both fields to the
CallbackHandler?

Chris Marshall
-- 
View this message in context: http://www.nabble.com/JAAS-in-Server-Password-Callback--tp23797070p23797070.html
Sent from the cxf-user mailing list archive at Nabble.com.


Re: JAAS in Server Password Callback?

Posted by cmarshall <cm...@courseadvisor.com>.
After some more digging (which I should have done before the first posting)
it looks like some of the issues are really WSS4J but not all.

First on the server side the message has (or should have) the username and
password and the use of a CallbackHandler seems a bit strange.  In most
other contexts (JAAS) a CallbackHandler is used to gather a username and
password when they have not already been supplied.

Second on the server side what is available to the CallbackHandler in the
passed WSPasswordCallback seems to vary depending on the password type.  If
I use WSContants.PW_TEXT then the password is included and if I use
WSContants.PW_DIGEST it is not.  After digging through the WSS4J code this
is in fact what it does and the CXF documentation does show this.  It does
seem strange that different password types would cause different behavior
with the CallbackHandler.

Third on the server side using WSContants.PW_DIGEST WSS4J expects the
CallbackHandler to retrieve a password for the user which is similar to
normal behavior for a CallbackHandler but in this case we are given a
username.  Every authentication system I have worked with in recent memory
performs at least a one way hash on passwords and stores the hash and thus
can't (and probably shouldn't) tell you what the password for a user is but
instead tell you the username and password combination is valid.

The above sounds like I would need to write my own interceptor, is this
correct or have I overlooked something?

Another posting had an example of retrieving the username and password from
the wsContext by casting it to WrappedMessageContext:

        WrappedMessageContext messageContext =
            (WrappedMessageContext)wsContext.getMessageContext();
        List recv = (List)messageContext.get("RECV_RESULTS");
        WSHandlerResult wsResult = (WSHandlerResult)recv.get(0);
        WSSecurityEngineResult wsseResult =
            (WSSecurityEngineResult)wsResult.getResults().get(0);
        WSUsernameTokenPrincipal principal =
           
(WSUsernameTokenPrincipal)wsseResult.get(WSSecurityEngineResult.TAG_PRINCIPAL);

Is this part of the API or is this relying on the way the current
implementation works?  In other words could I rely on this for the long
term?

Chris Marshall

cmarshall wrote:
> 
> The documentation for using WS-Security with CXF describes creating and
> configuring a CallbackHandler that is supposed to produce the password for
> a user so the calling routines can verify that the password is correct. 
> JAAS would expect that both the username and password would be supplied to
> it. Is there a way to configure the WSS4JInInterceptor to pass both fields
> to the CallbackHandler?
> 
> Chris Marshall
> 

-- 
View this message in context: http://www.nabble.com/JAAS-in-Server-Password-Callback--tp23797070p23802662.html
Sent from the cxf-user mailing list archive at Nabble.com.