Sorry, I know nothing about Weblogic.  Can't help you there.

 

I also didn't mean to imply that one should use TLS Clear text passwords but
I just thought I would bring it up ( I used digests for a while) in case
global hacking might be of concern. I actually had to change code in
Rampart/WSS4J to use clear text passwords in any case. Rampart/WSS4J expects
one to enter a password and return it and there was no way to get the clear
text password sent by the user in this callback. However, since you want to
work with digests there is no problem.

 

Brian

 

From: Liviu Florin Copot [mailto:[email protected]] 
Sent: Thursday, May 30, 2013 11:15 AM
To: [email protected]
Subject: Re: RAMPART - How to: UsernameToken Digest Password

 

Brian,

 

I used  (cb.getType().equals(WSConstants.PASSWORD_DIGEST)  to limit the
access to only digested passwords. Thank you!

 

However, I still feel I am doing the job of the application server's
authentication provider, since I need to have access to users and their
passwords. 

 

In a standard (using adnotations not axis2) webservice, I only need to add
the policy and Weblogic is implementing the username token validation, even
if the password is arriving digested. 

 

I feel that rampart should somehow integrate with the Weblogic
Authentication Providers in order to validate the username token. Am I
missing something?

 

Can anybody share some experience about running axis2+rampart on weblogic?

 

Thank you,

 

Liviu

 

 

 

 

 

 

 

On Thu, May 30, 2013 at 1:34 PM, Brian Reinhold
<[email protected]> wrote:

Liviu,

 

I did something like this in my PasswordCallback when I was using digested
passwords from the client:

 

                // Get clear text password from the server database

                    if(password != null)

                    {

                        if(cb.getType().equals(WSConstants.PASSWORD_DIGEST))

                        {

                            cb.setPassword(password);

                            break;

                        }

                        else

                        {

                            error = "No Password digest";

                        }

    }

 

In this case one must have on the receiving end the clear-text password
stored somewhere as that is the only way one can verify that the digest is
correct. This worked and clear-text passwords would fail by definition.

 

I considered that more dangerous than sending a clear text password using
TLS so I do not do this anymore. If you are using digested passwords from
the client you must have the clear text passwords stored on the server. If
someone hacks your server all those passwords are compromised. If someone
hacks the TLS send of the clear-text password and you store the passwords
digested on the server side, one password is compromised but all the others
are safe. Of course the server side will never know the user's password so
if the user forgets the user must create a new password.

 

Brian Reinhold

 

From: Liviu Florin Copot [mailto:[email protected]] 
Sent: Thursday, May 30, 2013 7:09 AM
To: [email protected]
Subject: RAMPART - How to: UsernameToken Digest Password

 

Dears,

 

I want to limit the access to an axis2 web service to allow only calls that
use UsernameToken with a Digest Password.

 

Following rampart sample01 I am able to enable rampart module and call the
webservice by providing "bobPW" as the password, in digested form. 

I call the service from SOAPUI. 

 

Problems I see so far, that prevent me from considering this as a production
solution:

1. PWCBHandler needs to use clear text passwords. 

2. The call is successfull even if the password is not digested, but in
clear text.

 

I looked arround trying to understand the usage of
javax.security.auth.callback.CallbackHandler but without much success so
far.

Is there any way to delegate the authentication of the user to the
application server (Weblogic) ?

 

Any suggestion about enforcing the password to be in digest form?

 

Thank you,

 

Liviu

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3343 / Virus Database: 3184/6367 - Release Date: 05/29/13

  _____  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3343 / Virus Database: 3184/6367 - Release Date: 05/29/13

 

Reply via email to