Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Div
classbreadcrumbs

Home / Single Sign-On and MFA / Current: EmpowerID Federation Overview

...

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.


Image RemovedImage Added


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.


Image RemovedImage Added


Info
iconfalse
titleFederated 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.


...