Authentication and Authentication Context

Single sign-on is the means by which a provider of either type can convey to another provider that the principal has been authenticated. Identity providers use local (to the identity provider) session information that is mapped to a user agent as the basis for issuing SAML authentication assertions to service providers. Thus, when the principal uses a user agent to interact with a service provider, the service provider requests authentication information from the identity provider based on the user agent's session information. If this information indicates that the user agent's session is presently active, the identity provider will return a positive authentication response to the service provider.

Access Manager accommodates these authentication actions:

• Supports a range of authentication methods (for example, password or certificate-based SSL).

• Allows providers to exchange the following minimum set of authentication information with regard to a principal: authentication status (active or not), instant (time authenticated), method, and pseudonym (temporary or persistent).

• Allows an identity provider, at the discretion of the service provider, to authenticate a principal by using an identity provider other than itself (proxy) and relay this information back to the service provider.

SAML is used for provider interaction during authentication but not all SAML assertions are equal. Different authorities issue SAML assertions of different quality. Therefore, the Liberty Alliance Project defines how the consumer of a SAML assertion can determine the amount of assurance to place in the assertion. This is referred to as the authentication context, information added to the SAML assertion that gives the assertion consumer information they need to make an informed entitlement decision. For example, a principal uses a simple identifier and a self-chosen password to authenticate to an identity provider. The identity provider sends an assertion that states the principal has been authenticated to a service provider. By sending the authentication context, the service provider can place the appropriate level of assurance on the associated authentication assertion. For example, if the service provider were a bank, they might require stronger authentication than that which has been used and send a response to the identity provider with a request to authenticate the user again. The authentication context information might include:

• The initial user identification mechanism (for example, face-to-face, online, or shared secret).

• The mechanisms for minimizing compromise of credentials (for example, private key in hardware, credential renewal frequency, or client-side key generation).

• The mechanisms for storing and protecting credentials (for example, Smartcard, or password rules).

• The authentication mechanisms (for example, password or Smartcard with PIN).

An XML schema has been defined by which the authority can assert the context of the SAML assertions it issues. The Liberty Alliance Project specifications have also defined Authentication Context classes against which an identity provider can claim conformance. The Liberty-defined authentication contexts are listed and described in the following table.

For more information on authentication context, see the Liberty ID-FF Authentication Context Specification.