Do the Right Thing

SAML 2.0 has the concept (originally defined in Liberty Alliance ID-FF) of Authentication Context. Authentication Context provides a set of related mechanisms by which IDPs and SPs can discuss the details behind an Authentication Statement. The IDP is able to provide details beyond the mere fact of authentication, and the the SP is able to indicate its requirements for such details.

Most people associate the <AuthnConext> element with capturing the specifics of how the user authenticated to the IDP, e.g. either using a password or (more meaningfully for maximizing the value of the SSO) some stronger authentication technology like a OTP or smartcard. This information can be important, all else being equal, an assertion issued after a smartcard authentication to the IDP is likely 'better' (from the SPs point of view) than one issued based on a password.

But Authentication Context is far more powerful than merely describing this aspect of the authentication (SAML 1.0 had an AuthnMethod mechanism that would have sufficed for this). Authentication Context gives IDPs and SPs a language to discuss many other aspects of the context of the authentication, including:

• The initial user identification mechanisms (for example, face-to-face, online, shared secret)
• The mechanisms for minimizing compromise of credentials (for example, credential renewal frequency, client-side key generation)
• The mechanisms for storing and protecting credentials (for example, smartcard, password rules)
• The authentication mechanism or method (for example, password, certificate-based SSL)

It's the SAML Authentication Classes (definitions of representative contexts for particular scenarios) for the mobile space that most obviously take advantage of this expressiveness.

For instance, the mobile oriented classes, in addition to distinguishing whether the user authenticated to the IDP with one or two factors, also distinguishes whether the IDP (likely the operator) has an account (and contract) for the user in question or whether the user is unregistered (using pay as you go cards etc). The former, with the implied opportunity for physical verification of identity that might be unavailable for a pay as you go user, might present a very different risk profile for an SP considering accepting an identity assertion from the operator IDP.

I've seen some object to the idea of Authentication Context, the view seeming to be 'Why doesn't the SP just trust the IDP to do the right thing?' If the IDP can only do one 'right thing', then that's fine. If your IDP does password authentication only and your use cases don't demand (or your security doesn't warrant) anything beyond, then all actors can be on the same page without any special mechanisms. If however the IDP has more options, then in many cases the SP will both need to be able to express its requirements of such options, and be informed as to the results.