ACEGI authorization with IssuerSerial-based certificates [SWS-52]

[gregturn]

Wayne L. Smith opened SWS-52 and commented

It is not possible to perform ACEGI certificate-based processing in Spring-WS (1.0 M2) when the certificate is not embedded in the header of the SOAP message.

When a certificate is embedded in a message, only CertificateValidationCallbacks are passed to the callback handlers. When a certificate is not embedded in the message (i.e., IssuerSerial reference), only SignatureVerificationKeyCallbacks are passed to the handlers. The KeyStoreCallbackHandler 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 (AcegiCertificateValidationCallbackHandler) 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.

Possible solutions:

• Modify AcegiCertificateValidationCallbackHandler to also process SignatureVerificationKeyCallback
• Create and use a new handler to perform ACEGI processing that accepts SignatureVerificationKeyCallback
• Somehow cause XWSS to fire off a CertificateValidationCallback when the certificate is IssuerSerial

---

Affects: 1.0 M2

Issue Links:

• If no BinarySecurityToken, i.e. IssuerSerial, no CertificateValidationCallback triggered for cert authentication by Acegi/JAAS - only signature check callback [SWS-234] #384 If no BinarySecurityToken, i.e. IssuerSerial, no CertificateValidationCallback triggered for cert authentication by Acegi/JAAS - only signature check callback
  ("is duplicated by")

[gregturn]

Arjen Poutsma commented

I'm afraid I can't fix this.

Basically, a SignatureVerificationKeyCallback requires a certificate to be set on it based some properties, it cannot be retrieved from it (yet). Acegi requires a certificate in order to validate. And like you said in the forum, there are no more callbacks after the key verification, XWSS uses internal mechanics to validate the certifificate.

This means that that the only way to make it work is to create a tight coupling between the KeyStoreCallbackHandler and the AcegiCertificateValidationCallbackHandler, so that when the certificate is loaded from the key store, it is passed to Acegi first. I don't really like that solution.

Hopefully, SUN will release a new version of XWSS soon, which can fix this.