Andy, All,
looking at the current implementation I would propose the following solution:
- leave passwordCallbackClass property. Renaming it would break all existing deployments. passwordCallackClass is not only used for UsernameToken but for _every_ method that needs a password.
- enhance the UsernameToken processing on the receiver side as follows:
- add new data elements to the WSPasswordCallback data structure to hold
the following new data elements: password, the string that identifies the
password type
- introduce a new WSPasswordCallback usage identifier USERNAME_TOKEN_UNKNOWN
- the processing of a UsernameToken with a password type _not equal_ to "Digest"
would be:
- populate WSPasswordCallback with user, password, password type string, and
usage identifier USERNAME_TOKEN_UNKNOWN
- call the callback class (if one is specified, i.e. the reference to the callback class
is not null)
- because the callback class is "user implemented" all necessary checks (also application
specific mechanisms can be applied here) can be performed.
- if the callback fails, e.g. the password is wrong or because of some other problems
it throws an excpetion - this way the security engine can throw its security exception
as well.
- if all is ok processing is as usual.
As an additonal modification I would propose to add the password type string to the
WSUsernameTokenPrincipal data structure to give an application all necessary information
to deal with application specific userame/password setup (this could be done in addition
to th above described handling)
The above proposal would required a small modification of existing callback classes: insert
the handling of callback usage USERNAME_TOKEN_UNKNOWN - could be as simple as
just a return.
Except from that the proposed modifications do not break existing deployments or interfaces
because the are just additions.
Any thoughts? I would like comments from those who are using UsernameToken or those
who could be affected by the modifications.
TIA.
Regards, Werner
Andy Kriger schrieb:
This has been mentioned up by several people now. I have pointed out previously that ignoring PasswordText creates a situation where developers are using the WSS4J library for security but the security can be bypassed if the client uses PasswordText. The developer is expected to roll their own solution for an aspect of the security that is in the specification but is not covererd by WSS4J (and it's not obvious that one needs to do this since the behavior is undocumented).
I proposed a solution a while back that would maintain consistency within WSS4J but never heard a response. From my previous email...
How about this: * rename the property "passwordCallbackClass" to "digestCallbackClass" * add support for a property "plaintextCallbackClass" * this new class would also implement CallbackHandler * in WSSecurityEngine.handleUsernameToken, an else block to the if(ut.isHashed) could handoff password processing to the plaintextCallbackClass (throwing an exception if it wasn't defined) and if handle threw an Exception, WSSecurityEngine would exit with a FAILED_AUTHENTICATION (that leaves all plaintext processing under the full control of the user)
However, because I'm not thoroughly versed in the source code, I don't know how that affects the creation/usage of WSUsernameTokenPrinicpal from there.
It's not ideal because the user is required to throw an exception from handle in order to trigger failure (as opposed to returning a value that can be checked), but it is consistent with existing functionality, doesn't require major changes (afaik), and doesn't let plaintext passwords escape authentication.
On 5/3/05, Dittmann Werner <[EMAIL PROTECTED]> wrote:
Ruchith,
WSS4J does not authticate if PasswordText is specified, it just returns the data to the application (Axis service). Also, in case of username token the password is optional.
Indeed you are right about the specification of the password callback: we shall make it optional in case of PasswordText.
Regards, Werner
-----Urspr�ngliche Nachricht----- Von: Ruchith Fernando [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 3. Mai 2005 11:26 An: WS-FX Betreff: UsernameToken authentication when a plain text password is used
Hi,
I noticed that WSSecurityEngine doesn't authenticate the UsernameToken when passwordType="PasswordText".
-------------------------------------------------------------- ------------------------------------------------------------- public WSUsernameTokenPrincipal handleUsernameToken(Element token, CallbackHandler cb) throws WSSecurityException { ..... ..... if (ut.isHashed()) { //Authenticates the UT }
WSUsernameTokenPrincipal principal = new WSUsernameTokenPrincipal(user, ut.isHashed()); principal.setNonce(nonce); principal.setPassword(password); principal.setCreatedTime(createdTime);
return principal; }
-------------------------------------------------------------- -------------------------------------------------------------
Is the above behaviour correct? If it is, in a situation where there's only a UsernameToken (passwordType="PasswordText") is sent in the security header, why should one specify the callback handler at the service deployment?
It's clear that the service impl can authenticate the UT as well, using the WSSecurityEngineResult vector from the msgContext, but why not authenticate at the Engine in the above instance?
OR have I missed something obvious :-) ?
Thanks in advance, Ruchith Fernando
