I’ve implemented everything you show above, plus I added this to ValidateUserTokenInterceptor, which I found at http://www.jroller.com/wookets/entry/cxf_acegi_ws_security_acegi

if (userTokenValidated) {
HttpServletRequest request = (HttpServletRequest) message.get(“HTTP.REQUEST”);
request.getSession(true).getId(); // necessary hack

// authenticate with acegi
final UsernamePasswordAuthenticationToken authReq =
new UsernamePasswordAuthenticationToken(principal.getName(), principal
.getPassword());

// message.HTTP_REQUEST_METHOD
authReq.setDetails(new WebAuthenticationDetails(request));

SecurityContextHolder.getContext().setAuthentication(authReq);
}

It looks like I’m just using WS-Security to pass through a username and password then, since I don’t see any more graceful way of telling WS-Security or CXF to use our Spring’s security configuration. Do you see any limitations or concerns with my approach?

Thanks


WSPasswordCallback pc = (WSPasswordCallback) callbacks[0];
String id = pc.getIdentifer();
username.set(id);
User user = userManager.getUserByUsername(id);
if (user != null) {
    pc.setPassword(user.getPassword());
    userData.set(user);
} else {
    throw new RuntimeException("Invalid Credentials");
}


public class PasswordHandler implements CallbackHandler {
public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException {
WSPasswordCallback pc = (WSPasswordCallback) callbacks[0];
pc.setPassword(pc.getPassword());
}
}

Do you know why this is even needed? It’s not doing anything useful. And all calls fail when I leave out this line from WSSecurityInterceptor:
props.put(WSHandlerConstants.PW_CALLBACK_REF, new PasswordHandler());

It works for me. But I’d prefer not to have useless code in place.

Thanks!

I would like to add following…

for those who need to access Spring context in any part of the application including CallbackHanders, this would be helpful

http://www.mail-archive.com/axis-user@ws.apache.org/msg22148.html

please update if you come across any better way of doing that.

Thanks,
Nilantha

Appreciate your help.

Regards,
Sai

public class ServerPasswordCallback implements CallbackHandler {
public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException {

WSPasswordCallback pc = (WSPasswordCallback) callbacks[0];

String strClientPwd = pc.getPassword();
int usage = pc.getUsage();

if(pc.getIdentifer().equals(“joe”)) {

String strServerPwd = “password”;

if(usage == WSPasswordCallback.USERNAME_TOKEN) { //PasswordDigest
pc.setPassword(strServerPwd);

}else if(usage == WSPasswordCallback.USERNAME_TOKEN_UNKNOWN) { //PasswordText
pc.setPassword(strServerPwd);

if(!strClientPwd.equalsIgnoreCase(strServerPwd)){ //DIY compare
throw new WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION);
}
}
}
}
}

Have you tried the case where you specify an invalid username/password or a valid username but an invalid password? Do you still receive the SoapFault?

In the following snippet from WSS4JInInterceptor.java
public void handleMessage(SoapMessage msg) throws Fault

if (wsResult == null) { // no security header found
if (doAction == WSConstants.NO_SECURITY) {
return;
} else {
LOG.warning(“Request does not contain required Security header”);
throw new SoapFault(new Message(“NO_SECURITY”, LOG), version.getSender());
}
}

If no security header found, a SoapFault is thrown. In my test, I set WS Security in server but not in client. And my client side does receive that SoapFault. So do we still need ValidateUserTokenInterceptor?

Thanks