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]
