ComponentPro UltimateSaml

Introduction to Single Sign-On Applications

Language Filter: AllSend comments on this topic to ComponentPro

Introduction

In web SSO, a user authenticates to one web site and then, without additional authentication, is able to access some personalized or customized resources at another site. SAML enables web SSO through the communication of an authentication assertion from the first site to the second which, if confident of the origin of the assertion, can choose to log in the user as if they had authenticated directly. An identity provider collects user identity information when the user logs in at the identity provider. The identity provider supplies service providers with a SAML assertion representing the identity of the user logged in at the identity provider. Service providers use the credentials in the SAML assertion to perform a local login at the service provider.

For further details refer to the OASIS standard (www.oasis-open.org).

Web Single Sign-On Use Case

Multi-domain web single sign-on is arguably the most important use case for which SAML is applied. In this use case, a user has a login session (that is, a security context) on a website (airline.example.com) and is accessing resources on that site. At some point, either explicitly or transparently, he is directed over to a partner's website (cars.example.co.uk). In this case, we assume that a federated identity for the user has been previously established between airline.example.com and cars.example.co.uk based on a business agreement between them. The identity provider site (airline.example.com) asserts to the service provider site (cars.example.co.uk) that the user is known (by referring to the user by their federated identity), has authenticated to it, and has certain identity attributes (e.g. has a “Gold membership”). Since cars.example.co.uk trusts airline.example.com, it trusts that the user is valid and properly authenticated and thus creates a local session for the user. This use case is shown in Figure 1, which illustrates the fact that the user is not required to re-authenticate when directed over to the cars.example.co.uk site.

SSOUseCase

Figure 1: General Single Sign-On Use Case

 

This high-level description indicated that the user had first authenticated at the IdP before accessing a protected resource at the SP. This scenario is commonly referred to as an IdP-initiated web SSO scenario. While IdP-initiated SSO is useful in certain cases, a more common scenario starts with a user visiting an SP site through a browser bookmark, possibly first accessing resources that require no special authentication or authorization. In a SAML-enabled deployment, when they subsequently attempt to access a protected resource at the SP, the SP will send the user to the IdP with an authentication request in order to have the user log in. Thus this scenario is referred to as SP-initiated web SSO. Once logged in, the IdP can produce an assertion that can be used by the SP to validate the user's access rights to the protected resource. SAML V2.0 supports both the IdP-initiated and SP-initiated flows. SAML supports numerous variations on these two primary flows that deal with requirements for using various types and strengths of user authentication methods, alternative formats for expressing federated identities, use of different bindings for transporting the protocol messages, the inclusion of identity attributes, etc. Many of these options are looked at in more detail in later sections of this document.