cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Rick.Ja...@swisscom.com>
Subject RE: Configured WS-Security UsernameToken PasswordDigest accepts PasswordText
Date Thu, 16 Jul 2009 10:23:41 GMT
Hello Glen,

thanx for the comprehensive explaination. We are using SSL and without nonce I see the point,
that we do not get any further security from PasswordDigest over PasswordText.

Independent of this fact, Colm gave the hint, how to implement the handler in order to accept
PasswordDigest but reject PasswordPlain. Sticking with the common example, the handler then
could look this way:

public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException
{

        logger.debug("ServerPasswordCallback.handle called.");
        WSPasswordCallback pc = (WSPasswordCallback) callbacks[0];

        if (pc.getUsage() != WSPasswordCallback.USERNAME_TOKEN) {
            throw new IOException("Wrong password type. The only allowed type is '" + WSConstants.PW_DIGEST
+ "'");
        }

        if (pc.getIdentifier().equals("joe")) {
            // set the password on the callback. This will be compared to the
            // password which was sent from the client.
            pc.setPassword("password");
        }
}

Thanx again for your support.

Regards,
Rick

-----Original Message-----
From: Glen Mazza [mailto:glen.mazza@gmail.com] 
Sent: Monday, July 13, 2009 4:54 PM
To: users@cxf.apache.org
Subject: RE: Configured WS-Security UsernameToken PasswordDigest accepts PasswordText


Ah yes.  I thought I saw that problem before: 
http://issues.apache.org/jira/browse/CXF-2150

But besides this issue, because CXF has not yet implemented the server-side nonce storage
(a largely necessary component for UsernameToken usage) you may wish to use Glassfish Metro
for UT profile security[1].  CXF is much better with the normal X.509 profile instead of username
token.

Be careful not to view password digest as necessarily more helpful than plain text because
it is encrypted back and forth -- you should still be requiring SSL as a minimum (as Metro
does here), which makes plain text password usage OK.  Another issue, user passwords on the
server-side are usually stored in encrypted format (in LDAP or a database).  Normally, you
take the incoming *plain text* password, apply the same encryption method as that used by
your local LDAP or database, and if they're the same, let the user in.  If you take an incoming
password digest, it can be much less helpful because, by definition of digests, you will not
be able to unencrypt it so you can subsequently re-encrypt it to compare it to the stored
LDAP/DB value.  Using password digests pretty much requires the encryption mechanism used
to create the digest be the *same* as the encryption method used by the LDAP/DB, so you can
do a direct comparison between the two--a regulation that may be difficult for your team to
enforce.

HTH,
Glen

[1]
http://www.jroller.com/gmazza/entry/implementing_ws_security_using_usernametokens


Rick.Janda wrote:
> 
> Hello Glen,
> 
> thank you for your response.
> 
> I read [1] before and now once again but I can not find any 
> explaination, how to make my service accept only PasswordDigest and reject PasswordText.
> 
>      <entry key="passwordType" value="PasswordDigest"/>
> 
> as contructor argument for WSS4JInInterceptor seems to be ignored 
> completely. With this configuration, the interceptor hands over all 
> PasswordText authentication requests to my handler that was designed 
> to autheticate PasswordDigest requests. So I'm not sure, what the 
> passwordType parameter is good for at the server side, if the  it does 
> not declare the authentication type that my service accepts.
> 
> And within the callback handler I can not check for PasswordDigest as 
> of
> pc.getPasswordType()
> will return 'null', if a security header with PasswordDigest was 
> submitted, thus
> 
>         WSPasswordCallback pc = (WSPasswordCallback) callbacks[0];
> 
>         if (!WSConstants.PW_DIGEST.equals(pc.getPasswordType())) {
>             throw new IOException("Wrong password type. The only 
> allowed type is '" + WSConstants.PW_DIGEST + "'");
>         }
> 
> in the callback handler does also not work, too.
> 
> I'm sorry, that I have to bother you again with my issue, but I would 
> be really grateful, if you could have a look at it again.
> 
> Thank you in advance,
> Rick
> 
> -----Original Message-----
> From: Glen Mazza [mailto:glen.mazza@gmail.com]
> Sent: Friday, July 10, 2009 9:41 PM
> To: users@cxf.apache.org
> Subject: Re: Configured WS-Security UsernameToken PasswordDigest 
> accepts PasswordText
> 
> 
> Yes, check[1], search on the text "Note that for the special case of a 
> plain-text password".  Hopefully this will get changed relatively soon[2].
> 
> [1] http://cwiki.apache.org/CXF20DOC/ws-security.html
> [2] https://issues.apache.org/jira/browse/WSS-183
> 
> Glen
> 
> 
> Rick.Janda wrote:
>> 
>> Do you have idea, how to make CXF rejecting anything else than 
>> PasswordDigest?
>> Or have I missed something in the documentation? 
>> 
> 
> 
> --
> View this message in context:
> http://www.nabble.com/Configured-WS-Security-UsernameToken-PasswordDig
> est-accepts-PasswordText-tp24432779p24433414.html
> Sent from the cxf-user mailing list archive at Nabble.com.
> 
> 
> 

--
View this message in context: http://www.nabble.com/Configured-WS-Security-UsernameToken-PasswordDigest-accepts-PasswordText-tp24432779p24463286.html
Sent from the cxf-user mailing list archive at Nabble.com.


Mime
View raw message