Hi all,
I've been using WSS4J for many years now quite happily, but I've
come across an issue I haven't found mentioned anywhere yet
and I wanted to run it by you.
When setting HandlerOptions on an Axis Service for UsernameToken
processing on the client, you can do one of two things for configuring
the PasswordCallback:
HashMap<String, Object> hOptions = new HashMap<String, Object>();
// options for username token handle
hOptions.put("action", "UsernameToken");
hOptions.put("passwordType", "PasswordDigest");
hOptions.put("deployment", "client");
hOptions.put("flow", "request-only");
hOptions.put("user", username);
And finally,
hOptions.put("passwordCallbackClass", "my.callback.class.name");
As you know, this causes an instance of this class to be created on the
fly,
its zero-arg constructor called, and then its handle() method executed.
The other option is:
hOptions.put("passwordCallbackRef", myCallBackClassObject);
This, theoretically, simply grabs the reference to the object I hand to
it and
calls its "handle" method, and if I botch that, well, it's garbage in,
garbage out.
What I've been chasing is failure to handle the passwordCallbackRef
option
appropriately, and I've chased it down to this:
in WSHandler(getPassword):799
else if ((cbHandler = (CallbackHandler) getProperty(mc, refProp))
!= null) {
Chasing through the various methods, the outcome is that this line
attempts to get the
CallbackHandler directly from the MessageContext property list only, but
does not also check the
HandlerOptions. What should instead be done is:
else if ((cbHandler = (CallbackHandler) getOption(refProp)) !=
null ||
(cbHandler = (CallbackHandler) getProperty(mc,
refProp)) != null) {
This searches for the CallbackHandler from the HandlerOptions which has
been set up as described
above as well as checking the MessageContext. This is identical in
operation to the way that the
"passwordCallbackClass" option is searched for, i.e. via the both the
HandlerOptions and the MessageContext.
I made this change to my local copy of the WSS4J 1.5.8 source and it
worked perfectly (or, at least, it
worked as I expected it to work). The order can be reversed depending
on which location for the property
you want to override the other, but the order I have above is identical
to the order in which PW_CALLBACK_CLASS
is searched.
So my discussion point boils down to this:
It looks as if only the MesageContext is searched for the
PW_CALLBACK_REF property and not
the HandlerOptions as well, as is the case for PW_CALLBACK_CLASS. It
seems to me as if this
is the incorrect behavior, and if that's the case, then the two-liner
above serves as a patch.
The good news is that there's a workaround which involves setting the
PW_CALLBACK_REF option on
every single Call Object created so that the option is in the
MessageContext, but I really don't
like having to do this! :)
Best Regards,
Benjamin Temko
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscr...@ws.apache.org
For additional commands, e-mail: wss4j-dev-h...@ws.apache.org
