You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Alessio Soldano <as...@redhat.com> on 2011/04/26 23:39:24 UTC
WS-Security Username Token w/ Digest issue on CXF 2.4
Hi,
I'm running a test leveraging WS-Sec UsernameToken profile for
authentication/authorization and in particular sends PasswordDigest type
passwords.
I have a custom interceptor that extends
org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor,
implementing the method
protected abstract Subject createSubject(String name,
String password,
boolean isDigest,
String nonce,
String created) throws
SecurityException;
in particular my interceptor relies on the isDigest boolean parameter
for internally using a digest aware callback handler. The problem I'm
seeing is that "isDigest" parameter is actually set as follows in
AbstractUsernameTokenAuthenticatingInterceptor:
@Override
protected void verifyDigestPassword(
org.apache.ws.security.message.token.UsernameToken
usernameToken,
RequestData data
) throws WSSecurityException {
if (!supportDigestPasswords) {
throw new
WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION);
}
String user = usernameToken.getName();
String password = usernameToken.getPassword();
boolean isHashed = usernameToken.isDerivedKey();
String nonce = usernameToken.getNonce();
String createdTime = usernameToken.getCreated();
AbstractUsernameTokenAuthenticatingInterceptor.this.setSubject(
user, password, isHashed, nonce, createdTime
);
}
as far as I understand, isHashed=usernameToken.isDerivedKey() considers
the Salt/Iteration elements that have been added in WS-Security
UsernameToken Profile 1.1. But when using 1.0 or simply only setting the
password type to digest, that parameter is false, hence the implementor
of createSubject method is not passed the proper info.
Did I miss something here? The same custom interceptor used to work
properly with CXF 2.3.x (Sergey originally wrote it :-) )
Thanks
Alessio
--
Alessio Soldano
Web Service Lead, JBoss
Re: WS-Security Username Token w/ Digest issue on CXF 2.4
Posted by Alessio Soldano <as...@redhat.com>.
Colm, Sergey,
thanks, my test is now passing with the latest trunk.
Cheers
Alessio
On 04/27/2011 11:08 AM, Sergey Beryozkin wrote:
> Hi Alessio, Colm
>
> Unfortunately I did not have a system test involving this interceptor
> checking digest passwords (I have the one for a policy first case
> though), so the regression was not spotted, thanks Colm for applying a
> fix.
>
> Alessio - as a workaround, while working with CXF 2.4.0, please override
>
> AbstractUsernameTokenAuthenticatingInterceptor.getSecurityEngine(boolean),
>
> and copy the code from the superclass but register another Validator
> implementation, which
> extends
>
> AbstractUsernameTokenAuthenticatingInterceptor.CustomValidator
>
> but overrides only its verifyDigestPassword method
>
> that should it till CXF 2.4.1 is released.
>
> One thing about using AbstractUsernameTokenAuthenticatingInterceptor
> is that it won't work in policy-first cases.
> Thus you might want to consider using another approach, extend
> org.apache.cxf.interceptor.security.AbstractUsernameTokenInterceptor
>
> which does not in turn extend WSS4JInInterceptor, please see
>
> http://cxf.apache.org/docs/security.html#Security-WSSecurityUsernameTokenandCustomAuthentication
>
> Thanks, Sergey
>
>
> On Wed, Apr 27, 2011 at 9:46 AM, Colm O hEigeartaigh
> <co...@apache.org> wrote:
>> Already taken care of..
>>
>> https://issues.apache.org/jira/browse/CXF-3476
>>
>> Colm.
>>
>> On Wed, Apr 27, 2011 at 9:32 AM, Alessio Soldano<as...@redhat.com> wrote:
>>> On 04/27/2011 10:30 AM, Colm O hEigeartaigh wrote:
>>>> Hi Alessio,
>>>>
>>>>> Did I miss something here?
>>>> No, it's a bug. It should be "isHashed" not "isDerivedKey".
>>>>
>>>> Colm.
>>> OK, I can open a jira and fix that, or you're already doing it?
>>> Thanks
>>> Alessio
>>>
>>> --
>>> Alessio Soldano
>>> Web Service Lead, JBoss
>>>
>>>
--
Alessio Soldano
Web Service Lead, JBoss
Re: WS-Security Username Token w/ Digest issue on CXF 2.4
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Alessio, Colm
Unfortunately I did not have a system test involving this interceptor
checking digest passwords (I have the one for a policy first case
though), so the regression was not spotted, thanks Colm for applying a
fix.
Alessio - as a workaround, while working with CXF 2.4.0, please override
AbstractUsernameTokenAuthenticatingInterceptor.getSecurityEngine(boolean),
and copy the code from the superclass but register another Validator
implementation, which
extends
AbstractUsernameTokenAuthenticatingInterceptor.CustomValidator
but overrides only its verifyDigestPassword method
that should it till CXF 2.4.1 is released.
One thing about using AbstractUsernameTokenAuthenticatingInterceptor
is that it won't work in policy-first cases.
Thus you might want to consider using another approach, extend
org.apache.cxf.interceptor.security.AbstractUsernameTokenInterceptor
which does not in turn extend WSS4JInInterceptor, please see
http://cxf.apache.org/docs/security.html#Security-WSSecurityUsernameTokenandCustomAuthentication
Thanks, Sergey
On Wed, Apr 27, 2011 at 9:46 AM, Colm O hEigeartaigh
<co...@apache.org> wrote:
> Already taken care of..
>
> https://issues.apache.org/jira/browse/CXF-3476
>
> Colm.
>
> On Wed, Apr 27, 2011 at 9:32 AM, Alessio Soldano <as...@redhat.com> wrote:
>> On 04/27/2011 10:30 AM, Colm O hEigeartaigh wrote:
>>>
>>> Hi Alessio,
>>>
>>>> Did I miss something here?
>>>
>>> No, it's a bug. It should be "isHashed" not "isDerivedKey".
>>>
>>> Colm.
>>
>> OK, I can open a jira and fix that, or you're already doing it?
>> Thanks
>> Alessio
>>
>> --
>> Alessio Soldano
>> Web Service Lead, JBoss
>>
>>
>
Re: WS-Security Username Token w/ Digest issue on CXF 2.4
Posted by Colm O hEigeartaigh <co...@apache.org>.
Already taken care of...
https://issues.apache.org/jira/browse/CXF-3476
Colm.
On Wed, Apr 27, 2011 at 9:32 AM, Alessio Soldano <as...@redhat.com> wrote:
> On 04/27/2011 10:30 AM, Colm O hEigeartaigh wrote:
>>
>> Hi Alessio,
>>
>>> Did I miss something here?
>>
>> No, it's a bug. It should be "isHashed" not "isDerivedKey".
>>
>> Colm.
>
> OK, I can open a jira and fix that, or you're already doing it?
> Thanks
> Alessio
>
> --
> Alessio Soldano
> Web Service Lead, JBoss
>
>
Re: WS-Security Username Token w/ Digest issue on CXF 2.4
Posted by Alessio Soldano <as...@redhat.com>.
On 04/27/2011 10:30 AM, Colm O hEigeartaigh wrote:
> Hi Alessio,
>
>> Did I miss something here?
> No, it's a bug. It should be "isHashed" not "isDerivedKey".
>
> Colm.
OK, I can open a jira and fix that, or you're already doing it?
Thanks
Alessio
--
Alessio Soldano
Web Service Lead, JBoss
Re: WS-Security Username Token w/ Digest issue on CXF 2.4
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Alessio,
> Did I miss something here?
No, it's a bug. It should be "isHashed" not "isDerivedKey".
Colm.
On Tue, Apr 26, 2011 at 10:39 PM, Alessio Soldano <as...@redhat.com> wrote:
> Hi,
> I'm running a test leveraging WS-Sec UsernameToken profile for
> authentication/authorization and in particular sends PasswordDigest type
> passwords.
> I have a custom interceptor that extends
> org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor,
> implementing the method
>
> protected abstract Subject createSubject(String name,
> String password,
> boolean isDigest,
> String nonce,
> String created) throws SecurityException;
>
> in particular my interceptor relies on the isDigest boolean parameter for
> internally using a digest aware callback handler. The problem I'm seeing is
> that "isDigest" parameter is actually set as follows in
> AbstractUsernameTokenAuthenticatingInterceptor:
>
> @Override
> protected void verifyDigestPassword(
> org.apache.ws.security.message.token.UsernameToken usernameToken,
> RequestData data
> ) throws WSSecurityException {
> if (!supportDigestPasswords) {
> throw new
> WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION);
> }
> String user = usernameToken.getName();
> String password = usernameToken.getPassword();
> boolean isHashed = usernameToken.isDerivedKey();
> String nonce = usernameToken.getNonce();
> String createdTime = usernameToken.getCreated();
> AbstractUsernameTokenAuthenticatingInterceptor.this.setSubject(
> user, password, isHashed, nonce, createdTime
> );
> }
>
> as far as I understand, isHashed=usernameToken.isDerivedKey() considers the
> Salt/Iteration elements that have been added in WS-Security UsernameToken
> Profile 1.1. But when using 1.0 or simply only setting the password type to
> digest, that parameter is false, hence the implementor of createSubject
> method is not passed the proper info.
> Did I miss something here? The same custom interceptor used to work properly
> with CXF 2.3.x (Sergey originally wrote it :-) )
>
> Thanks
> Alessio
>
> --
> Alessio Soldano
> Web Service Lead, JBoss
>
>