Authentication and Authentication Context

SSO is the means by which a provider of either type can convey to another provider that a principal has been authenticated. Authentication is the process of validating user credentials; for example, a user identifier accompanied by an associated password. You can authenticate users with OpenSSO Enterprise in the following ways:

• Use a policy agent to insert HTTP header variables into the request object. This functions for web applications only.

• Use the authentication API to validate and retrieve user identity data. This will work with either web or non-web applications.

Identity providers use local (to the identity provider) session information 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. OpenSSO Enterprise allows providers to exchange the following minimum set of authentication information with regard to a principal.

• Authentication status (active or not)

• Instant (time authenticated)

• Authentication method

• Pseudonym (temporary or persistent)

SAML v1.x 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 ID-FF 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 the details they need to make an informed entitlement decision. For example, a principal uses a simple identifier and a self-chosen password to authenticate to a service provider. The identity provider sends an assertion to a second service provider that states how the principal was authenticated to the first service provider. By including the authentication context, the second service provider can place an appropriate level of assurance on the associated assertion. If the service provider were a bank, they might require stronger authentication than that which has been used and respond to the identity provider with a request to authenticate the user again using a more stringent context. The authentication context information sent in the assertion 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, smart card, or password rules).

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

The Liberty ID-FF specifications define authentication context classes against which an identity provider can claim conformance. The Liberty ID-FF authentication contexts are listed and described in the following table.

For more information, see the Liberty ID-FF Authentication Context Specification and . Additionally, there is an XML schema defined which the identity provider authority can use to incorporate the context of the authentication in the SAML assertions it issues.