Single Sign-On Explained

So what is SSO and why do I care?

 
SSO is an acronym for “Single Sign-On”.  There are various forms of single sign-on with the most common being Enterprise Single Sign-On (ESSO) and Web Single Sign-On (WSSO).

Each method utilizes different technologies to reduce the number of times a user has to enter their username/password in order to gain access to protected resources.

Note: There are various offshoots from WSSO implementations – most notably utilizing proxies or portal servers to act as a central point of authentication and authorization.

Enterprise Single Sign-On

 

In ESSO deployments, software typically resides on the user’s desktop; the desktop is most commonly Microsoft.  The software detects when a user launches an application that contains the username and password fields.  The software “grabs” a previously saved username/password from either a local file or remote storage (i.e. a special entry in Active Directory), enters these values into the username and password fields on behalf of the application and submits the form on behalf of the user.  

This process is followed for every new application that is launched that contains a username and password field.  It can be used for fat clients (i.e. Microsoft Outlook), thin clients (i.e. Citrix), or Web-based applications (i.e. WebForms), and in most cases the applications themselves are not even aware that the organization has implemented an ESSO solution.  

There are definite advantages to implementing an ESSO solution in terms of flexibility.  The drawback to ESSO solutions, however, is that software needs to be distributed, installed, and maintained on each desktop where applications are launched.  Additionally, because the software resides on the desktop, there is no central location in which to determine if the user is allowed access to the application (authorization or AuthZ). As such, each application must maintain its own set of security policies.

The following diagram provides an overview of the steps performed in ESSO environments.
 


 

A user launches an application on their desktop.   An agent running in the background detects a login screen from a previously defined template.  If this is the first time the user has attempted to access this application, they are prompted to provide their credentials.  Once a successful login has been performed, the credentials are stored in a credentials database.  This database can be a locally encrypted database or a remote server (such as Active Directory).  Subsequent login attempts do not prompt the user for their credentials.  Instead, the data is simply retrieved from the credentials database and submitted on behalf of the user.
 

Container-Based Single Sign-On

 
Session information (such as authenticated credentials) can be shared between Web applications deployed to the same application server.  This is single sign-on in its most basic and limited fashion as it can only be used across applications in the same container.

The following diagram provides a high level overview of the steps performed in container-based single sign-on environments.
 


 

A user accesses a Web application through a standard Web browser.  They are prompted for their credentials which can be basic (such as username and password) or can utilize other forms of authentication (such as multi-factor, X.509 certificates, or biometric).  Once the user has authenticated to the application server, they are able to access other applications installed in the same J2EE container without having to re-authenticate (that is, if the other applications have been configured to permit this).
 

Traditional Web Single Sign-On

 In contrast, WSSO deployments only apply to the Web environment and Web-based applications.  They do not work with fat clients or thin clients.  Software is not installed on the user’s desktop, but instead resides centrally within the Web container or J2EE container of the Web application being protected.  The software is often times called a “policy agent” and its purpose is to manage both authentication and authorization tasks.

The following diagram provides a high level overview of traditional Web Single Sign-On.
 

A user first attempts to access a Web resource (such as ADP) through a Web browser.  They are not authenticated to the domain so they are directed to the central authentication server where they provide their credentials.  Once validated, they receive a cookie indicating that they are authenticated to the domain.  They are then redirected back to the original Web resource where they present the cookie.  The Web resource consults the authentication server to determine if the cookie is valid and that the session is still active.  They also determine if this user is allowed access to the Web resource.  If so, they are granted access.  If the user were to attempt to access another Web resource in the same domain (i.e. Oracle eBusiness Suite), they would present the cookie as proof that they are authenticated to the domain.  The Web resource consults the authentication server to determine the validity of the cookie, session, and access rights.  This process continues for any server in the domain that is protected by WSSO.

Portal or Proxy-Based Single Sign-On

Portal and proxy-based single sign-on solutions are similar to Standard Web Single Sign-On except that all traffic is directed through the central server.

Portal Based Single Sign-On

 Target-based policy agents can be avoided by using Portal Servers such as LifeRay or SharePoint.  In such cases the policy agent is installed in the Portal Server.  In turn, the Portal Server acts as a proxy for the target applications and may use technologies such as SAML or auto-form submission.  Portal Servers may be customized to dynamically provide access to target systems based on various factors.  This includes the user’s role or group, originating IP address, time of day, etc.  Portal-based single sign-on (PSSO) serves as the foundation for most vendors who are providing cloud-based WSSO products. 

When implementing PSSO solutions, direct access to target systems is still permitted.  This allows users to bypass the Portal but in so doing, they need to remember their application-specific credentials.  You can disallow direct access by creating container-specific rules that only allow traffic from the Portal to the application.

Single Sign-On Involving Proxy Servers

Proxy servers are similar to PSSO implementations in that they provide a central point of access.  They differ, however, in that they do not provide a graphical user interface.  Instead, users are directed to the proxy through various methods (i.e. DNS, load balancers, Portal Servers, etc.).

Policy agents are installed in the proxy environment (which may be an appliance) and users are granted or denied access to target resources based on whether they have the appropriate credentials and permission for the target resource.

The following diagram provides a high-level overview of centralized single sign-on using Portal or Proxy Servers.
 

Federation

Federation is designed to enable Single Sign-On and Single Logout between trusted partners across a heterogeneous environment (i.e. different domains).  Companies that wish to offer services to their customers or employees enter into a federated agreement with trusted partners who in turn provide the services themselves.  Federation enables this partnership by defining a set of open protocols that are used between partners to communicate identity information within a Circle of Trust.  Protocols include SAML, Liberty ID-FF, and WS-Federation.

Implementation of federated environments requires coordination between each of its members.  Companies have roles to play as some entities act as identity providers (IDP – where users authenticate and credentials are verified) and service providers (SP – where the content and/or service originate).  Similar to standard Web Single Sign-On, an unauthenticated user attempting to access content on a SP is redirected to an appropriate IDP where their identity is verified.  Once the user has successfully authenticated, the IDP creates an XML document called an assertion in which it asserts certain information about the user.

The assertion can contain any information that the IDP wishes to share with the SP, but is typically limited to the context of the authentication.  Assertions are presented to SPs but are not taken at face value.  The manner in which assertions are validated vary between the type of federation being employed and may range from dereferencing artifacts (which are similar to cookies) or by verifying digital signatures associated with an IDP’s signed assertion.

The interaction between the entities involved in a federated environment (user, SP and IDP) is similar to the Web Single Sign-On environment except that authentication is permitted across different domains.

A major difference between federated and WSSO environments involves the type of information generated by the authenticating entity to vouch for the user and how it is determined that that vouch is valid and had not been altered in any way.

The following table provides a feature comparison between Web SSO and Enterprise SSO.