Overview#
Single Sign-On (
SSO) implies that once the
Entity has been Identified, no further
Authentications are required.
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.)
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.
Perhaps we need a Graded Authentication
There might be more information for this subject on one of the following: