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.
Table 11–2 Authentication Context Classes
Class |
Description |
---|---|
MobileContract |
Identified when a mobile principal has an identity for which the identity provider has vouched. |
MobileDigitalID |
Identified by detailed and verified registration procedures, a user's consent to sign and authorize transactions, and DigitalID-based authentication. |
MobileUnregistered |
Identified when the real identity of a mobile principal has not been strongly verified. |
Password |
Identified when a principal authenticates to an identity provider by using a password over an unprotected HTTP session. |
Password-ProtectedTransport |
Identified when a principal authenticates to an identity provider by using a password over an SSL-protected session. |
Previous-Session |
Identified when an identity provider must authenticate a principal for a current authentication event and the principal has previously authenticated to the identity provider. This affirms to the service provider a time lapse from the principal's current resource access request. Note – The context for the previously authenticated session is not included in this class because the user has not authenticated during this session. Thus, the mechanism that the user employed to authenticate in a previous session should not be used as part of a decision on whether to now allow access to a resource. |
Smartcard |
Identified when a principal uses a smart card to authenticate to an identity provider. |
Smartcard-PKI |
Identified when a principal uses a smart card with an enclosed private key and a PIN to authenticate to an identity provider. |
Software-PKI |
Identified when a principal uses an X.509 certificate stored in software to authenticate to the identity provider over an SSL-protected session. |
Time-Sync-Token |
Identified when a principal authenticates through a time synchronization token. |
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.