Security :: Single Sign On (SSO) and SAML v2.0
What is Singe Sign On?
As enterprises use more SaaS applications, they are encountering a familiar problem from the world of premises apps: as the number of log-in credentials grow, users resort to poor password security practices, such as choosing simple or common passwords, and storing passwords in easily accessible places. This can become a security and administrative nightmare for IT departments. The answer, as usual in such situations, is Single Sign On.
Single Sign On, also known as SSO, allows users to have access to multiple applications by signing in using only one account to different systems and resources.
SSO is most useful when there are various systems that can be accessed by using a single password, and we want to prevent repeated access to them each time the user is disconnected from the service. This is highly convenient for users, since, by identifying themselves just once, it is possible to maintain a valid session for the rest of the applications which use SSO.
The Technical Jargon
Before discussing the available standards and technologies, it’s important to define the jargon used by security experts around authentication. When examining various authentication protocols, the standards distinguish between an identity provider (IDP) and a relying party (RP) or service provider (SP). The former is the service that creates and manages the user identity and performs the actual authentication on behalf of other services. The latter is the system that determines whether to grant user access based on validated credentials presented by the IDP.
The easiest way for most enterprises to unify internal and external user identities is to use their internal SSO system, such as a corporate-wide Active Directory, as an IDP. Then they can build “connections” to various SaaS providers, which act as RP/SPs. There are several ways to create these connections. The specific implementation will vary widely depending on a company’s internal SSO architecture, its menu of SaaS services (and the mechanisms the SaaS providers support) and the enterprise’s security requirements.
The Standards
Probably the most complete and versatile standard for exchanging authentication information is the Security Assertion Markup Language (SAML, for short), developed by OASIS. Its maturity, security and flexibility have made SAML the foundation among large enterprises, governments and service providers for building so-called federated identity architectures.
Three other standards primarily target end users and public Web services, but may also be required or supported by some enterprise SaaS providers. These are OpenID (used by Facebook, Google, PayPal and Yahoo, among others), Information Cards (used by Windows Cardspace) and OAUTH (developed by Twitter).
Worksoft SaaS supports SAML V2.0 currently and does not support any other standard including OpenID and OAUTH.
SAML V2.0
SAML version 2.0 was approved as an OASIS Standard in March 2005. The complete SAML 2.0 OASIS Standard set (PDF format) and schema files are available in this zip file.
SAML 2.0 is an XML-based protocol that uses security tokens containing assertions to pass information about a principal (usually an end user) between a SAML authority, named an Identity Provider, and a SAML consumer, named a Service Provider.
SAML 2.0 enables web-based, cross-domain SSO, which helps reduce the administrative overhead of distributing multiple authentication tokens to the user.