Federation Overview

From an IT perspective, federation encapsulates the processes and technologies that support trusted, secure connections across diverse systems, entities, and domains within the context of a Single Sign-On (SSO). Much like a Domain Controller allows authenticated Active Directory users the ability to access network resources hosted by differing servers, federated SSO allows users to login once and access different applications across unrelated systems without being prompted to login multiple times. Using this principle, federation can be a powerful tool that secures your applications and resources while giving your users a more friendly experience.

For example, an enterprise with an online presence could have multiple partners and clients who need to access applications provided by that organization via the Internet. In addition, some of these partners and clients could have partners and clients of their own, whom, by virtue of their relationships, might also need to access some of the enterprise's resources. Without federation, that enterprise would need to create separate user accounts for each individual and then maintain those accounts as if they belonged to their own employees. The oversight needed in such a scenario would be a daunting task, time-consuming and costly, with the threat of security breaches from accounts no longer valid potentially devastating. In addition, external users would need to adopt another "digital identity," with another set of login credentials to maintain. In the age of the social networking, blogs, wikis, and never-ending Web services, the odds favor eventual forgotten or compromised passwords. With federation, those risks are significantly lessened.

Federated Identity Management

SSO can be implemented for systems within the same enterprise, across multiple enterprises, and even across the Web (as Cloud or browser-based SSO) between cooperating parties so that users with multiple digital identities in disparate systems can discretely link those identities together for easier access to each party's resources. This is known simply as "federated identity management."

In any federated identity management transaction, there are always three actors involved: the subject or user, the identity provider (IdP), and the service provider (SP) or relying party (RP). Subjects are the users of resources about whom an identity management transaction concerns. Identity providers are those parties that authenticate users, asserting to their identity. Service providers are those parties that provide services to users based (in part) on the authentication events that occur between the IdP and the user. They rely on the integrity of the assertion supplied to them by the IdP to properly identity the user.

As a high-level representation of how user identities are federated between identity providers and service providers, let's consider the following example where a user, "Ima User," makes a request to a service provider, "MySP.com," and is authenticated by her favorite identity provider, "MyIdP.com." In addition, MySP.com and MyIdP.com have mechanisms in place that allow them to trust what one another say about a user's identity.

To begin the transaction, Ima User visits MySP.com and clicks on a link provided by MySP.com requesting to login with her identity at MyIdP.com.

MySP.com responds by redirecting Ima User's browser to MyIdP.com with an authentication request. MyIdP.com asks Ima User to authenticate using her MyIdP.com credentials. After she authenticates, MyIdP.com generates an assertion of her identity, signs and encrypts it, and then passes the assertion back to MySP.com with a form post redirect to MySP.com's assertion consumer service. MySP.com verifies the integrity of the response and links Ima User's identity in MySP.com with her identity at MyIdP.org. From this point forward, each time Ima User chooses to authenticate to MySP.com with her MyIdP.com identity, MySP.com will grant her access to all the resources to which she is entitled, just as if she directly logged in to MySP.com.

The sequence for this transaction is as follows:

1. From her browser, Ima User navigates to MySP.com and clicks a link provided by MySP.com requesting to login with her identity at MyIdP.com.
2. MySP.com redirects Ima User's browser to MyIdP.com with an authentication request.
3. MyIdP.com asks Ima User to authenticate and then redirects her browser back to MySP.com with an assertion of her identity there.
4. MySP.com consumes the assertion and federates Ima User's identity at MyIdP.com with her identity at MySP.com. Ima User can now log in to MySP.com with her MyIdP.com identity.

Federated Identity Standards

Organizations wishing to federate identities with one another must have mechanisms in place that allow them to trust what each other have to say about user identities. 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. As an Identity Management Platform, EmpowerID is extremely flexible, supporting all major federated identity standards in use today to include Security Assertion Markup Language (SAML), OpenID, OAuth, WS-Fed, and WS-Trust.

Federated Identity Standards

Mapping Identities in EmpowerID

As was mentioned earlier, EmpowerID functions as both an IdP and an SP. As an IdP, EmpowerID allows users to authenticate into EmpowerID via their Web browsers to access resources and services from EmpowerID as well as any other SPs federated with EmpowerID. As a service provider, EmpowerID allows users authenticated with secondary IdPs federated with EmpowerID to access any resources in EmpowerID to which they are authorized. Key to securing these identity transactions in EmpowerID is theLogin Workflow.

Login as a Workflow

The EmpowerID platform offers a unique technology advance for Adaptive SSO called the Login Workflow. The Login Workflow is a fully adaptable EmpowerID workflow that runs each time an unrecognized user authenticates to EmpowerID, whether that authentication event occurs directly or via SSO from a federated IdP. The Login Workflow must run before that user is granted access to any Service Provider (even if EmpowerID was not the authenticating IdP). The Login Workflow acts as an adaptable policy enforcement point where security policies such as second factor authentication and device registration can be applied and combined before a user is allowed access to SSO protected systems. Common policy options include adding additional authentication factors, forced password changes, terms of use acceptance, and more.

The Login Workflow also handles on-demand joining and provisioning of identities as a user logs in. When a user logs in with an identity from a trusted identity provider, the Login Workflow checks to see if there is an account from that IdP in EmpowerID that is linked to an EmpowerID Person. If that is the case, the user is permitted to log in and all policies are applied. If there is not an account from that IdP linked to an EmpowerID Person, the login workflow will evaluate any "Join" logic to determine if there is an EmpowerID Person to whom the account can be joined. If the answer is yes, then the account is either joined to the Person or routed to an administrator for approval. If the account cannot be joined to an existing Person, the Login Workflow gives the user the option to register the account with EmpowerID or exit the application. The registration process can be automatic or routed for approval as required.

Protocol Flows

Expanding on the example used earlier to describe the general flow that occurs between SPs and IdPs, let's discuss in greater detail the actual flow that occurs in SAML-based identity transactions between EmpowerID and another entity.