My blog has moved and can now be found at

No action is needed on your part if you are already subscribed to this blog via e-mail or its syndication feed.

Sunday, March 30, 2008
« Threat Modeling | Main | IEEE Security & Privacy on Identity ... »

Some time ago, I was having a conversation with some folks about the usage of SAML Authentication Assertions for Web Browser Single Sign-On (SSO) versus Digital Certificates.  The folks that I was having this conversation with support one of the larger PKI deployments in the US, and their response to my comment about the lack of support for SAML for Web Browser SSO in that particular vertical was the following question:

"Provided the experience to the user is the same, why does it matter?"

I didn't have a very good answer at that point in time but it is something that I've been mulling over since that time. The issue has come up again in separate conversations, including this one by Patrick Harding of Ping Identity and this posting by James McGovern.  This blog posting is an attempt to articulate some of the points on both sides of this debate.

SAML 2.0 and Web Browser SSO

The Web Browser SSO Profile in SAML 2.0 supports both an Identity Provider (IdP) initiated and Service Provider (SP) initiated SSO message flows. As described in the SAML documentation ".. the most common scenario for starting a web SSO exchange is the SP-initiated web SSO model which begins with the user choosing a browser bookmark or clicking a link that takes them directly to an SP application resource they need to access. However, since the user is not logged in at the SP, before it allows access to the resource, the SP sends the user to an IdP to authenticate. The IdP builds an assertion representing the user's authentication at the IdP and then sends the user back to the SP with the assertion.  The SP processes the assertion and determines whether to grant the user access to the resource.

In an IdP-initiated scenario, the user is visiting an IdP where they are already authenticated and they click on a link to a partner SP. The IdP builds an assertion representing the user's authentication state at the IdP and sends the user's browser over to the SP's assertion consumer service, which processes the assertion and creates a local security context for the user at the SP."

Some points to keep in mind regarding these two flows:

  • The user's credentials are maintained at their IdP, which means that the SP must trust the IdP to assert information about its users. The establishment of this "organizational trust" is typically done out of band.
  • The IdP can support multiple authentication mechanisms of varying strengths including user-id/password, software certificates and smart-cards based on a PKI, biometrics etc.
  • The type and the strength of the authentication used by the user can be conveyed in a SAML authentication context which can be used in (or referred to from) a SAML Authentication Assertion. In fact an SP can include an authentication context in a request to an IdP to request that the user be authenticated using a specific set of authentication requirements, such as a multi-factor authentication.
  • Do not conflate authentication with authorization! Although the user has been authenticated, the SP more than likely needs a LOT more information about the user (than what was provided in the Authentication Assertion) in order to make an access control decision.  This typically requires the usage of SAML attribute statements and/or SAML authorization decision statements. And in any reasonably complex environment that wants to remain standards based, this more than likely involves the usage of XACML for defining access control criteria.
  • SAML supports mechanisms to support the integrity and confidentiality of the assertions themselves including SSL mutual authentication, XML Signature etc. and does so across both the HTTP and SOAP bindings.

PKI and Web Browser SSO

This is pretty straight forward from the usage perspective. It begins with a user choosing a bookmark or clicking a link that takes them directly to a Relying Party (RP) i.e. application resource they need to access.  The user is prompted to present a digital certificate as the authentication mechanism.  The user's certificate, whether it is in the form of a soft certificate or coming from a smart card, is used to authenticate the user.

Some points to keep in mind:

  • In a PKI environment, when a Certification Authority issues a certificate, it is making a statement to a RP that a particular public key is bound to a specific entity (i.e. the subject of the certificate).
  • The degree to which a RP trusts a CA is based on the RP's understanding of the CA's user identification and credential issuance practices, operating policies, security controls etc.
  • Depending on the identity issuance requirements of a CA, the digital certificate is usually consider a higher assurance authentication mechanism than something like a user-id and password.
  • Each RP has to put into place the technical infrastructure needed to make it PKI-aware i.e. the ability to use digital certificates as authentication mechanism.
  • Each RP has to put into place the mechanisms for both validation and revocation operations. This is especially challenging when you have CA's that are cross-certified and CA's and clients need to support certificate path processing.
  • The user experience, in browsing from one PKI protected resource to another may not be seamless.
  • The authorization aspect is indeed separate from the authentication.  Information needed to make an access control decision may not be present in the information provided by a digital certificate.

What strikes me when I look at these two options is that the question posed at the start of this entry may not be the right one to ask. The question one should be asking instead is "Who do you trust?"

The fundamental precept of a PKI environment is that everyone must buy into trusting the CA. I would bet that that a lot of the "entrenched PKI communities" have expended significant amount of resources in standing up not just the technical infrastructure but the credential proofing and issuance processes for their domain. As such, they implicitly trust a certificate vouched for by the CA. The downside to this is that every single RP must be PKI-enabled, which is non-trivial.

SAML is not a trust mechanism but more of a mechanism for a particular domain to make assertions about its users. As such, what is needed in the federated world for this to work is for a relying domain to trust the asserting domain. The relying domain would have to have confidence in the credential proofing and issuance process of the asserting domain. The advantages here would be that SAML-enabling an SP is a more straight forward process and there is significant out-of-the-box support for SAML in vendor tooling.

In each case, I consider authorization to be separate and distinct from the authentication.

But that organizational trust... Ah!  Is it not remarkable that the truly hard problems, whether one is discussing Identity Management or Service Orientation, really do not have to do with technology but with people, culture and behavior? tags: , ,

Technorati tags: , ,
Tags:: Security
3/30/2008 8:59 PM Eastern Standard Time  |  Comments [2]  |  Disclaimer  |  Permalink   
Monday, March 31, 2008 8:45:11 AM (Eastern Standard Time, UTC-05:00)
Regarding trust, I think it bears mentioning the expanding role of the United States government Federal Bridge Certificate Authority and the growing number of organizations and federations that either already cross certified or that likely will be. In particular the managed PKI service providers who have cross certified (e.g. Verizon/Cybertrust, Entrust, Verisign) and offer certificates and in combination with others smart cards tied to these CAs.

Keep an eye on RFC 5055, this is pretty close to a standard and will provide a means of establishing trust beyond the assumption that "I trust that CA and the way they issue certificates and this one has not been revoked"

I completely agree on the issue of authentication versus authorization. One point often overlooked is the ability to embed in the OCSP response a role in the extension. Under this scenario you would get both revocation checking and role in one fell swoop.

Finally I think that the continuing evolution of the federal smart card standard (FIPS 201) will matter in this area. As this community continues to grow with federal employees, contractors (HSPD-12), transportation workers (TWIC) , first responders and critical infrastructure (FRAC) it begins to become the case where this evolves into the enterprise standard for identity particularly as it addresses the requirements for a converged multi-use credential for logical, physical and other types of access control.
Thursday, April 17, 2008 5:19:51 PM (Eastern Daylight Time, UTC-04:00)

I read with great interest on you "Authentication, SAML and PKI" blog article.

You state exact words that I use in daily presentations/discussion on this topic, namely:

"In each case, I consider authorization to be separate and distinct from the authentication."

It is this statement where I would like to expound on your prescepts and have think about another dynamic in the "Authentication, SAML and PKI" arena. That is simply: a PKI authentication is extremely compatible to a SAML (2.0) federated model.

See Diagram:

This is exactly what MultiFactor has executed in Google Apps integrations. In this scenario, a site host MultiFactor SecureAuth(R) authentication and the original identities to become a trusted IdP (Identity Party) and the Google Apps site is the RP (Relying Party). The authentication is conducting by MultiFactor SecureAuth with a valid X.509 authentication occurring. (MultiFactor has many patents-pending on the uniqueness of the ability to deploy via WebServices the necessary PKI infrastructure and distribute the X.509 certificates to end users - but for that's for another discussion. See:

What is germane here is that a valid bi-lateral, X.509 authentication is conducted by an IdP (Identity Party) that is hosting the identities and SecureAuth for authentication. The IdP in turn, creates a SAML 2.0 assertion which is trusted by the Relying Party - and thus the end user achieves integration into the application.

In this model - only the IdP needs to have a trusted PKI "infrstructure", in this case an easy to deploy SecureAuth authentication module.

Thus, it is MultiFactor's believe that SAML and PKI (if PKI is deployed simply and manageably via SecureAuth) are compatible and in fact inseparable in a trusted, scalable, federated environment.

Garret Grajek, CISSP
MultiFactor Corporation
Chief Operating Officer
office: 949.777.6970
mobile: 714.658.0765

Comments are closed.