PART A:

Has anyone else had this problem? I have a simple STS Username token request
for a SAML token where the username token is as follows:

<wsse:UsernameToken wsu:Id="UsernameToken-ID">
        <wsse:Username>myName</wsse:Username>
        <wsse:Password
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token
-profile-1.0#PasswordText">myPassword</wsse:Password>
</wsse:UsernameToken> 


On the receive side there is a callback to verify the username token

    public void handle(Callback[] callbacks) throws IOException,
            UnsupportedCallbackException
    {
        for(Callback callback: callbacks)
        {
            WSPasswordCallback cb = (WSPasswordCallback)callback;
            int callbackType = cb.getUsage();
            switch(callbackType)
            {
                case WSPasswordCallback.USERNAME_TOKEN:
                try
                {
                        if(cb.getType().equals(WSConstants.PASSWORD_TEXT))
                        {
                            String myPassword = cb.getPassword();
                    ...

The returned 'myPassword' is null. Any ideas why?

PART B:

It looks like that is by design. The callback apparently must always supply
the password. This is very restrictive. In this use case passwords are not
stored, only password digests are stored. The password is then sent in the
clear (not really, its TLS) and the same algorithm is applied to the
password received as to the users password in the database. But to use this
approach one has to be able to retrieve the password from the message. I do
not want to store passwords in reversible encrypted forms. There is a much
higher likelihood of security breach of MANY passwords.

I need a work a round. Get the message context in the callback seems the
only way. The uglier alternative is to have the client take the password,
compute the same digest as I do, and send it as clear text'. Stinks since it
is not interoperable.




---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org



-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2890 / Virus Database: 2638/6032 - Release Date: 01/14/13

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2890 / Virus Database: 2638/6032 - Release Date: 01/14/13


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org

Reply via email to