PKI and SAML - Friends or Foes

One of the reasons that SAML based Federation exists is that wide-spread use of user certificates never materialized. If it had, then it is unlikely that SAML would be what it is today as user certificates themselves can securely solve the cross-domain web SSO problem.

That said, there have been some industries that have been willing to invest the money to make PKI work at scale for large user communities. As such we at Ping have struggled to justify the value of SAML in these entrenched PKI communities that already rely on user digital certificates for authentication and cross-domain web SSO.

We have been recently discussing with a number of these communities a security architecture where federation is useful in addition to user certificates. In this architecture SAML Assertions are used solely for authorization purposes rather than for the more generally accepted purpose of authentication/SSO. Their issue is that digital certificates are not well suited for conveying directory based attribute information, such as user role and group designations, that is used for making authorization decisions. These user attributes can change over relatively short periods of time. While they will continue to authenticate users and systems with certificates, they plan to leverage SAML Assertions to communicate user attributes between applications in different domains. These attributes will be used to make authorization decisions.

For example, if a user from Domain A turns up at an application in Domain B they will be authenticated by that application with their cert as usual. But the application in Domain B needs certain user attributes to make authorization decisions that are in the directory in Domain A. SAML Web SSO is used to request a SAML Assertion from Domain A that contains the necessary user attributes. The user will also be required to authenticate to Domain A with their certificate before the SAML Assertion is made available to Domain B.

This security architecture supports a decentralized identity infrastructure rather than requiring a centralized directory infrastructure. It also alleviates the need for directory synchronization between domains. While the back channel SAML Attribute Query/Response protocols could also be used for retrieving SAML Assertions, there are significantly greater deployment headaches associated with setting up SOAP based back channel bindings. The front channel, browser based POST/Redirect bindings are much simpler to deploy. The SAML Assertion and the attributes themselves are integrity protected via an XML Signature, and optionally can be kept confidential with the use of XML Encryption.