axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tony Dean" <>
Subject RE: [axis2] rampart security
Date Sun, 27 Aug 2006 23:13:19 GMT
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?


-----Original Message-----
From: Ruchith Fernando [] 
Sent: Saturday, August 26, 2006 10:25 PM
Subject: Re: [axis2] rampart security


On 8/26/06, Tony Dean <> 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

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 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.




> 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
> SAS... The Power to Know
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message