Using PasswordDigest (or PasswordText) over an insecure channel is dangerous since these tokens can be replayed (unlike with HTTP Digest Auth, the digest value isn't based on the message content). You can implement replay detection for UsernameTokens that use PasswordDigest by using the Nonce and Timestamp.
You could pass an encrypted UsernameToken containing a PasswordText around in multi-hop scenarios, but they can also be replayed (I don't need to break the encryption if I can just resend the encrypted token). You would have to implement some other form of reply detect potentially based on a signature binding the token to a message id and/or timestamp. Thanks, Mike "Tony Dean" <[EMAIL PROTECTED]> wrote on 08/27/2006 07:13:19 PM: > Yes, I understand that you can use a clear text UserNameToken and > perform the authentication myself. But, as you say I will need to > use a secure transport (via SSL). That presents some complexities > with multi-hop scenarios. I'd like to have an end to end solution > with application level security. What are my options? > > Thanks. > > -----Original Message----- > From: Ruchith Fernando [mailto:[EMAIL PROTECTED] > Sent: Saturday, August 26, 2006 10:25 PM > To: [email protected] > Subject: Re: [axis2] rampart security > > Hi, > > On 8/26/06, Tony Dean <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I have been looking at the rampart security add-in for axis2 and I > have some concerns. > > > > Let's just take UserNameToken for example. > > > > If I set my service to require a UserNameToken digest as follows: > > > > <parameter name="InflowSecurity"> > > <action> > > <items>UsernameToken</items> > > <passwordCallbackClass>myCBHandler</passwordCallbackClass> > > </action> > > </parameter> > > > > At runtime my service's callback will be passed the invoking > user's name (pulled from the SOAP Header). It is my understanding > that the callback should return the user's password at which time > rampart can recreate the digest and compare it against the digest > that was passed by the invoking client. Is this correct? If so I > do not know any real world security system that will allow a service > to obtain a clear text password. I do not think it is plausible for > a service to obtain such information. > > This behaviour is *only* enforced when the UsernameToken uses a > digest of the password as the password.This digest is not a direct > digest of the password and its the digest of the combination of > nonce, created and password values. The 'nonce' is a set of random > bits and the created is the bytes of the created time in yyyy-MM- > dd'T'HH:mm:ss'Z' > format. This nonce and created values are available in the UT element. > > Now in authenticating the user in the above case, WSS4J will have to > construct the digest using the nonce and created info available in > the UsernameToken AND the password obtained from the service. THIS > IS ONLY POSSIBLE WHEN THE PLAIN TEXT PASSWORD IS AVAILABLE. > > BUT .... > > We have an alternative... The UsernameToken can be configured to > contain a plain text password. In this case the "password" child > element of the UT element will contain the actual password of the > user. In the server side Rampart/WSS4J expects the callback handler > implementation to handle the authentication and provides the > user/pass values into the callback handler. (See sample03 in [1]). > At the callback handler one can use the password sent in the UT > element to transform it to any form that is comparable with the form > of password that is stored in the user info store. For example, is > the user info store holds the SHA1 digests of passwords of users, > then one can simply create the SHA1 digest of the password value > provided and compare it with the value in the store. > > If you are using the plain text password make sure you use a secure > transport such as HTTPS. > > > > > I was really hoping that rampart would do something like > Websphere. If I configure a web service in Websphere to require a > UserNameToken, it will handle the entire authentication process > (based on the configured AuthenticationProvider) and only call into > the web service implementation operation if authentication is > successful. At that point, the web service can get the > authenticated user principal out of the ServiceEndpointContext and > perform authorizations based on that principal. > > Yes! This is somewhat possible with Rampart. > > Provided you have configured a callback handler to carryout > authentication as explained above, WSS4J (What rampart is based on) > will create a WSUsernameTokenPrincipal (implements > java.security.Principal) instance with the username token info and > this can be retrieved at the service or any handler after the > security inflow handler. You will be able to perform your > authorizations based on this principal. > > HTH > > Thanks, > Ruchith > > [1] http://www.wso2.net/presentations/wss4j/java/2006/08/04/apache-rampart > > > > > Service's really are really not going to want to perform their own > authentication processing. They will want to leverage this value > from the container. > > > > Please comment. > > > > Thanks. > > > > Tony Dean > > SAS Institute Inc. > > 919.531.6704 > > [EMAIL PROTECTED] > > > > SAS... The Power to Know > > http://www.sas.com > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > www.ruchith.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
