Single Sign-On (SSO) by George Hernandez

Exploring Single Sign-On (SSO).

Intro

Single sign-on (SSO) is related to access control of multiple related but independent software systems. A user will be authenticated by one resource, and then when the same user accesses other resources, those resources will check with the authenticating resource.

In access control, there are 3 parts:

Authentication. Verifying that a user is who they claim they are. This is the primary conern of SSO; OpenID deals with authentication.
Authorization. Administering which users and groups of users get access to which resources with what permissions. SSO is sometimes involved with authorization; OAuth deals with authorization.
Auditing. Tracking which users did what to which resources when. SSO rarely deals with authentication.

Identity management has to do with managing authentication and authorization data. Identity management and access control may be used for:

A single software system within a site/client/company. Identity management desirable.
Multiple software systems within a site/client/company. Identity management and SSO desirable.
Multiple software systems across two or more sites/clients/companies. Federated Identity management and federated SSO desirable.

Open SSO

OpenID is an open standard concerned with decentralized authentication. OpenID is decentralized in the sense that OpenID authentication can be provided by a variety of Identity Providers. It is also notable that in OpenID the authentication method is not fixed and can range from the common user name and password to multi-factor such as smart cards, SMS to cell phones, and biometrics.

Here is a typical OpenID scenario:

An OpenID Identity Provider (OIP) has users that it authenticates and does identity managment. The OIP provides its users an OpenID URL or XRI. EG: georgelhernandez.myopenid.com.
A service provider that needs authenticated users is a Relying Party (RP). A RP may use multiple OIPs. A RP usually handles its own authorization and auditing.
Once a user has been set up at an OIP, then he or she can either authenticate at the OIP and then visit RPs, or visit RPs who will then check with the OIP.

Security Assertion Markup Language (SAML) is conceptually the same as OpenID except that SAML is an XML-based open standard from OASIS that deals with authentication and authorization. In SAML-speak you have an Identity Provider (IdP) and a Service Provider (SP). Just from the terminology you can hear that OpenID is less stuffy than SAML. OpenID is to SAML, as REST is to SOAP.

SSO Implementations

There are SSO implementations (open and proprietary) that build upon open and proprietary code. See List of single sign-on implementations [W].

The SSO implementations vary in degree of implementation.

Some just do non-federated SSO, some do federated SSO.
Some do identity management, some don't.
Some store your ACL data, some hook into your pre-existing ACL data in something like Microsoft Active Directory (AD, formerly NT Directory Service); AD uses Lightweight Directory Access Protocol (LDAP) versions 2 and 3, Kerberos and DNS.
Some do fancier authentication like multi-factor authentication (EG: SMS authentication).

Here are some SSO implementations that I've personally looked into:

IBM Tivoli.
- Tivoli Access Manager for e-business (TAMeb): $25/user @ 50 users, price break at ~1000 users. Pure Web SSO. ACL usually LDAP, Microsoft Active Directory, or Tivoli Directory Server.
- Tivoli Access Manager for Enterprise SSO (TAMesso): $36-50/user. Requires client sw but can access web, telnet, mobile, network, extranets
- Tivoli FIM is $394,000.
CA SiteMinder. $20K.
Oracle Oblix.

Single Sign-On (SSO)

Intro

Open SSO

SSO Implementations

Links