"As part of my work for the National Institute of Informatics and the UPKI initiative, I've been working on a modified Web Browser SSO profile for SAML 2.0 that uses holder-of-key confirmation for the client rather than bearer authentication. The keys for this confirmation are supplied through TLS using client certificates. This results in a more secure sign-on process and, particularly, a more secure resulting session at the SP. There is no need for the SP to do PKI validation or know anything about the client certificate itself. The specification supplies an alternative to "Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0."
Excerpt: "The profile allows for transport and validation of holder-of-key assertions by standard HTTP user agents with no modification of client software and maximum compatibility with existing deployments. Most of the flows are as in standard Web Browser SSO, but an x.509 certificate presented by the user agent supplies a valid keypair through client TLS authentication for HTTP transactions. Cryptographic data resulting from TLS authentication is used for holder-of-key validation of a SAML assertion. This strengthens the assurance of the resulting authentication context and protects against credential theft, giving the service provider fresh authentication and attribute information without requiring it to perform successful validation of the certificate...
A principal uses an HTTP user agent to either access a web-based resource at a service provider or access an identity provider such that the service provider and desired resource are understood or implicit. In either case, the user agent needs to acquire a SAML assertion from the identity provider. The user agent makes a request to the identity provider using client TLS authentication.
The X.509 certificate supplied in this transaction is used primarily to supply a public key that is associated with the principal. The identity provider authenticates the principal by way of this TLS authentication or any other method of its choice. The identity provider then produces a response containing at least an assertion with holder-of-key subject confirmation and an authentication statement for the user agent to transport to the service provider. This assertion is presented by the user agent to the service provider over client TLS authentication to prove possession of the private key matching the holder-of-key confirmation in the assertion.
The service provider should rely on no information from the certificate beyond the key; instead, it consumes the assertion to create a security context. The TLS key may then be used to persist the security context rather than a cookie or other application-layer session.
To implement this scenario, a profile of the SAML Authentication Request protocol is used in conjunction with the HTTP Redirect, HTTP POST and HTTP Artifact bindings. It is assumed that the user is using an HTTP user agent capable of presenting client certificates during TLS session establishment, such as a standard web browser...
See the full coverage of Nathan Klingenstein (ed)'s OASIS Security Services (SAML) Technical Committee Contribution in Cover Pages.
