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
