A typical SP today tends to ignore identity assurance or authentication quality issues because contracts and other compensating controls are used to deal with risks "out of band". An occasional exception is the checking of "authentication method" values from a SAML assertion to require stronger authentication such as hardware tokens or certificates. These are most commonly all or nothing exercises, usually internal to an organization, and thus subject to a lot of explicit configuration by the IdP to support.
A partial goal of an assurance program the Assurance Program is to move more of these considerations "in band" to support more complex requirements and in particular to support applications that need to negotiate for higher assurance in real time or that may have differing requirements based on what the user is trying to do.
At least in SAML, the theoretical basis for using the
<saml:AuthnContext> construct to represent assurance is that the protocol already includes feautures features for requesting and negotiating the right result. In practice, this gets becomes complex as the use case becomes more complicated; some of the reasons can be found in the parallel discussion about regarding Identity ProvidersProvider Behavior.
See Assurance - Identity Provider Behavior for some of the relevant background.
Some SAML SP implementations do not support the use of
<samlp:AuthnRequest> messages at all, or do not allow for the use of the
<samlp:RequestedAuthnContext> element to specify the SP's requirements. In such a case, IdPs would have to allow for out of band configuration of their behavior based on the identity of the SP. It may also be possible to supplement the SP with application code that can generate a request on behalf of the broken implementation.
In turn, the SP implementation may or may not have the ability to actually consume the IdP's asserted
<saml:AuthnContext> information, or affect application behavior based on it. In that scenario, obviously the SP is essentially back to relying entirely on out of band assumptions; this is essentially what most deployments do nowtoday.
So for our purposes let's assume these constraints don't hold, at least to some degree. Ideally , then, SPs that require a particular assurance level (or one of a set) will initiate the assurance flow by including the desired identity assurance qualifier (IAQ) in the
<samlp:AuthnRequest> message. SPs should understand that asking for a particular IAQ implies that the result may be a SAML error rather than a successful authentication response, because the IdP may be unable to comply. (Errors are always possible of course, but they are more likely in the presence of
<samlp:RequestedAuthnContext>.) To avoid such an error, the SP and the IdP will need to agree on a catch-all value that means "or anything you can handle". InCommon recommends using "
urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified" for this purpose.
SPs will receive IAQs (either in response to a specific request, or sent unsolicited) in assertions from IdPs. Exactly one IAQ is available, but some IdPs may provide values that predate the assurance program (often a signal that the user authenticated with a password) or may provide an IAQ that the SP does not recognize.
What does the standard require an SP to do?
Nothing. If it doesn't care about assurance, it doesn't have to do anything. If it does careIf the SP intends to request one or more qualifiers, then it has to determine what it's prepared to accept, and where appropriate, configure itself to include the acceptable values in its
SAML doesn't address this specifically because there's really nothing to support at that layer; it's really a matter for the SP and application to address by ensuring that crossing such a boundary results in a second request to the IdP. The main concern is really state. If the application's state is maintained separately from the SAML implementation, then simply re-invoking the SAML authenticaton step with different request content may be sufficient.
Advice to SP Deployers
The specific practices to follow depend largely on the use case for assurance that one has. We are collecting material on use cases identified by the community as valuable.
A concrete piece of advice across all use cases is to document as extensively as possible what your service's requirements, assumptions, and expectations are with regard to assurance so that IdPs can evaluate their systems, and understand the errors that their users might be experiencing. One would expect in the short run that most assurance-requiring services are going to involve some degree of setup and testing, so this documentation will be critical. Think of it as akin to the material used to define attribute requirements for users.
To populate the
<samlp:RequestedAuthnContext> element in the SP's requests, the
AuthnContextClassRef content setting can be used.
The Shibboleth SP only minimally handles this, by surfacing it as a "FatalProfileException" and displaying an error template. Most of the time, such errors represent unusual or rare conditions, which makes them different from this one. As a result, we recommend that deployers experiment with the SP's
redirectErrors content setting and route errors to an application script to deal with. Complete documentation on error handling is available.