Single Sign-On Scenarios

Overview[1]#

There are many scenarios for single sign-on using federation. The scenarios differ based on the location of the user account login being used for authentication, the location of the applications being accessed, and which party hosts the federation server(s) that enable single sign-on.

In general, an organization will need to support multiple scenarios in order to support employee, partner, and customer access control to internal applications as well as employee access control to Cloud or partner applications.

We discuss a successful approach to the most common SSO scenarios.

The Solution: Standards-Based Federation#

A flexible standards-based federation solution that enables users to login once and then access applications without being prompted to login again is the key to solving these critical business challenges.

Single Sign-On (SSO) is the most important of services offered by identity federation because it allows employees, customers, and partners to access multiple Cloud or internal corporate applications using a single username and password. Furthermore, federated SSO allows users who are authenticated against one directory to access additional applications and services without re-authenticating when a trust relationship has been established, removing the need for users to remember multiple usernames and passwords by enabling single sign-on between organizations.

Organizations wishing to federate with one another require Authentication Methods in place that allow them to trust what each other has to say about user identities. A Circle of Trust is a federation of Identity Provider (IDP) and Service Providers (SP’s) with legal, business and operational agreements that ensure seamless, secure data transactions for their members and users. These mechanisms are defined in part by the federated identity standards adopted by each organization. Federated Identity standards make it possible for organizations to interchange identity data in a way that allows them to talk intelligently with one another. An important criterion for any federation system is the ability to support all major federated identity standards in use today, including Security Assertion Markup Language (SAML), OpenID Connect, OAuth 2.0, WS-Fed, and WS-Trust in order to enable the broadest possible set of Federation relationships.

In any federated Identity Management transaction, there are always three actors involved:

Service provider initiated#

There are two ways that single sign-on can be initiated in a SAML SSO scenario. Service Provider initiated SSO is when a user attempts to access the Service Provider application and is redirected to an Identity Provider (IDP) for authentication because they do not have a current login session. After authenticating at the Identity Provider (IDP), the user is redirected back to the Service Provider with an assertion of their identity.

Identity Provider (IDP) Initiated SSO#

In Identity Provider (IDP) Initiated SSO, the Identity Provider (IDP) is configured with specialized links for each Service Provider application. These links refer to the URL of the local Identity Provider (IDP)'s single sign-on service and pass parameters to the service identifying the remote Service Provider. So instead of directly visiting the Service Provider, the user goes to the Identity Provider (IDP) site and clicks on one of the links to gain access to the remote Service Provider. This triggers the creation of an assertion which is passed back to the user’s browser and then automatically posted to the Service Provider allowing SSO access.

Scenario: Corporate Login to Cloud Application#

The Corporate Login to Cloud Applications Single Sign-On scenario is when a user logs in once using their corporate user credentials and then is able to access Cloud applications without being prompted again for authentication. This is the most commonly supported SSO scenario in corporate IT organizations. A typical example is of a user logging in with their Microsoft Active Directory credentials and then browsing to use a Cloud application like Salesforce.com without being asked to re-authenticate. In this scenario, the corporation hosts the Federation server that enables SSO with Cloud applications based on standard protocols like SAML, OAuth 2.0 or OpenID Connect. Corporate Login to Cloud Application SSO has become so ubiquitous that virtually all SaaS providers support standards-based federated SSO.

Benefits of this approach:

The Cloud Login to Internal Application Single Sign-On scenario, also known as Social Media Login, is when an organization allows users to login to corporate application using their Social Website credentials.

Cloud Login to Internal Application SSO is commonly supported when an organization wants to extend access for internal applications to consumers who are already accustomed to using their Cloud Logins to access sites on the Internet. A familiar, consumer-friendly model like this is easy to use and decreases support costs associated with a large consumer population.

Examples of commonly used Cloud Logins would be Facebook, Google, Windows Live, Yahoo, or Twitter.

A typical scenario of this is a consumer logging into a corporate SharePoint website with their Facebook account.

Benefits of this approach:

Scenario 3: Corporate Login to Internal Application#

The Corporate Login to Internal Corporate Application single sign-on scenario occurs when a user logs in once using their corporate user credentials and is then able to access any internal corporate applications without being prompted for authentication.

An example of this is when a user logs in with their Active Directory account and then browses to an internally-hosted SharePoint site that is in a different, untrusted Active Directory Forest managed by a different division. This scenario is often required by organizations as they acquire other companies but cannot create trusts between their Microsoft Active Directory domains due to legal limitations imposed by differing localities, time constraints or other internal policies.

Another example of this scenario is organizations that are developing new applications internally. Best practice security architecture is to decouple authentication/authorization from within each application and to leverage centralized services for these functions. In this case, internal applications would be developed as "Relying parties" that trust an internal corporate identity management system for authentication/authorization decisions.

Benefits of this approach:

Scenario 4: Corporate Login to Partner Application#

The Corporate Login to Partner Application single sign-on scenario occurs when a user logs in once using their corporate user credentials and then is able to access any external corporate applications made available by an organization’s business partners without being prompted again to authenticate.

A typical example of this would be a user logging in with their Active Directory user account and then browsing to a partner organization’s SharePoint site that is hosted and managed at the partner organization and linked into their corporate directory.

In this scenario, single sign-on is achieved by the creation of a federation trust between the federation servers at the user’s organization and those at the partner organization. When the user attempts to access the partner’s exposed application (e.g. SharePoint), the partner application redirects the user to the federation login screen on the partner organization federation server. The user would be presented with an option or tile to login with their corporate credentials, which when clicked would redirect them back to their corporate federation server for authentication. Upon authentication, the user’s federation server would redirect them back to the partner federation server which then sends them into the application.

Benefits of this approach:

Scenario 5: Identity as a Service (IDaaS) Hub#

In this scenario, users log in with an identity maintained by a Cloud Identity as a Service (IDaaS) Provider and can then access multiple Cloud hosted SaaS applications or corporate hosted partner applications without being prompted to re-authenticate. Typically, the IDaaS provider will maintain processes to support registration, delegated administration, and a user interface for end users to see links they may click on to login via IDP-Initiated SSO-POST access partner or affiliate Service Provider applications.

In the IDaaS Hub scenario, a group of organizations agree to leverage a shared Identity Provider (IDP) service in order to facilitate application sharing between them. A central shared Identity Provider functions as a hub of authentication, allowing an Identity Trust Framework to be established with all major Identity Providers using industry-standard protocols like SAML, WS-Federation, WS-Trust, OpenID, OAuth, and OpenID Connect. The Identity Trust Framework simplifies the creation and maintenance of federation trusts by allowing an organization to only configure their applications to trust one Identity Provider. Smaller member organizations can configure their Service Provider applications to directly trust the IDaaS system, while larger organizations with an in-house federation system can configure as an Identity Broker to trust with the IDaaS federation services. Federation connections only need to be made once between partner systems and the central Identity as a Service (IDaaS) federation provider, with new services becoming immediately available to all subscribers of the service.

This is a much more cost effective solution when there are a large number of organizations that require federation and that utilize a common set of applications, preventing the exponential increase in costs as the number of federation partnerships increases. These cost savings create strong incentives for organizations to provide these shared Identity Service partnerships. This scenario is more common in specific industries such as healthcare where hospitals and doctor’s practices partner with insurance companies and health care plans.

Benefits of this approach:

More Information#

There might be more information for this subject on one of the following:
Please see our Copyright And Intellectual Property Page and Standard Disclaimer Pages!