LDAPWiki: Single Sign-On

Overview#

Single Sign-On (SSO) or Federated Authentication implies that once the Entity has been Identified, no further Authentications are required.Single Sign-On or Federated Authentication may follow one or more Federation Models.

Typically, this is done through some form of Identity Broker application.

Many people confuse Consistent Sign-On (CSO) with Single Sign-On and often what Organizations end up with is Reduced Sign-On (RSO).

There are several specific implementations of Single Sign-On:

Many Organizations heterogeneous approach to Single Sign-On implementing one or more through an Identity Broker type product.

Often, Single Sign-On applications will implement a form of Identity Brokering to allow Cross-domain authentication and/or Cross-platform Authentication

Single Sign-On usually also involves a Identity Federation.Single Sign-On may be provided as part of a Cloud Access Security Broker

Many Single Sign-On target applications have an internal User Store. Thus, before an End-User can use Single Sign-On to a target application, the Organizational Entity must first add (or provision) the user to that application.

OpenID Connect Federation often does not require User Provisioning (however the application may still require provisioning.)!! Single Sign-On and Authorization Many Single Sign-On implementations do not provide Authorization to the level that may be required.

Some of the more common Single Sign-On Scenarios.

As Single Sign-On has grown to often include all Organizational Entity's Applications and perhaps even Federated Applications we now have all our eggs in one basket. Compromise of one entity's Password might allow access to HR Applications or to Financial Applications where the entity could have Administration permissions.

There might be more information for this subject on one of the following: