ACEGI authorization with IssuerSerial-based certificates

[wlsmith]

I've been working with digitally signing our WS messages to support both authentication and authorization. I'm using XwsSecurityInterceptor with two callback handlers:

1. a KeyStoreCallbackHandler to validate the certificates, followed by
2. an AcegiCertificateValidationCallbackHandler to authenticate and configure the ACEGI security context.

I'm only checking signatures on incoming messages; outgoing responses are unsigned. Everything seems to work fine as long as the SOAP header contains the BinarySecurityToken, but it gets a little confusing when the message is signed with the IssuerSerial option (i.e., the certificate isn't included in the header, just a reference to a certificate that must already be known to the server).

When the certificate is embedded in the message, only CertificateValidationCallbacks are passed to the callback handlers. Everything works (but is possibly redundant?), since both handlers deal with that callback. The KeyStore handler processes it first and the ACEGI handler looks up UserDetails and configures the security context.

When the certificate is not embedded in the message (i.e., IssuerSerial), only SignatureVerificationKeyCallbacks are passed to the handlers. The KeyStore handler understands this one, and it does its job just fine: the certificate is found if already known to the server. The problem is that the ACEGI handler is not invoked, since it only understands the CertificateValidationCallback. So there is no way to configure the ACEGI security context unless the certificate is embedded in the message.

I figure I can make a custom callback handler that handles the SignatureVerificationKeyCallback and performs the desired ACEGI processing. However, the fact that the SignatureVerificationKeyCallback doesn't occur when the certificate is embedded make me think I'm not understanding something. Is this an XWSS feature, or something Spring-WS could control?

Thanks for any help!

[Arjen Poutsma]

snip

When the certificate is embedded in the message, only CertificateValidationCallbacks are passed to the callback handlers. Everything works (but is possibly redundant?), since both handlers deal with that callback. The KeyStore handler processes it first and the ACEGI handler looks up UserDetails and configures the security context.

The two handlers are not redundant. The first handler checks whether the certificate has not been expired, and whether a trust path can be created for it. The second one checks whether the certificate is valid in your context.

When the certificate is not embedded in the message (i.e., IssuerSerial), only SignatureVerificationKeyCallbacks are passed to the handlers. The KeyStore handler understands this one, and it does its job just fine: the certificate is found if already known to the server. The problem is that the ACEGI handler is not invoked, since it only understands the CertificateValidationCallback. So there is no way to configure the ACEGI security context unless the certificate is embedded in the message.

I figure I can make a custom callback handler that handles the SignatureVerificationKeyCallback and performs the desired ACEGI processing. However, the fact that the SignatureVerificationKeyCallback doesn't occur when the certificate is embedded make me think I'm not understanding something. Is this an XWSS feature, or something Spring-WS could control?

This sounds like an issue I can fix. Could you create a JIRA issue here: http://opensource.atlassian.com/proj...ing/browse/SWS

Thanks for spotting this!