How to configure XKMS in an XML Gateway policy

XKMS (XML Key Management Services) provides a way to perform certificate validation using Web Services standards such as SOAP and XML. It gets around the problem that OCSP is often not used. For example, it is an interesting fact that many browsers support OCSP and CRLs, but do not actually enable them, because they may add latency to page loads. XKMS could be an answer for that problem. However, it has to be said that XKMS never really took off. The difficulties around certificate management continue to be about issuing and managing the certificates themselves, not the protocols to validate them.

Here we see a sample policy before we add XKMS. You can see that the policy, configured in Policy Studio, is performing WS-Security X.509 Authentication and then is running a shortcut to a sub-policy (think of it like a subroutine) to examine the incoming XML for threats. Then, it is performing dynamic routing.



We now drag in an XKMS filter, so that we will validate the client's certificate after we perform WS-Security X.509 Certificate Authentication. This is dragged from the Certificate "drawer" on the right of Policy Studio, and dragged into the policy canvas itself.

It is important that the XKMS responder does not become a bottleneck for the whole policy. To that end, we setup a group of XKMS responders which will be cycled through. If one is down, the other will be used. If both is down, a "Fatal" condition is raised which can then be managed at the policy level. This is an important technique to use for any identity management connector.



Next we see the XKMS filter added to the policy. Notice that we've also dropped in an alert filter, and we raise an alert if the client's certificate fails XKMS validation. We also promptly block the message in that situation also. You could also customize a message back to the client in the event of XKMS validation failing (such as "Please check your certificate validity").



XML Gateway performing double-duty as an XKMS responder

Notice how Policy Studio's certificate "drawer" also contains filters which implement OCSP, CRLs, and other certificate trust checks. It is easy to imagine how you can create an actual XKMS responder using the XML Gateway. In that case, the XML Gateway would receive the XKMS SOAP message, and then would validate the certificate using "traditional" non-XKMS methods, and then return an XKMS response. In that case, the XML Gateway is the XKMS responder. That cuts out the requirement for a seperate XKMS responder as part of the architecture, since it's something which they XML Gateway can perform.