You are viewing an earlier version of the admin guide. For the latest version, please visit EmpowerID Admin Guide v7.211.0.0.

Federation Overview

Owned by Phillip Hanegan
Dec 10, 2020
30 min read

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."

By discretely linking, we mean that the login of a user in one system is never disclosed to the other system.

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.

The roles between IdPs and SPs can often be interchanged as IdPs and SPs can both be an identity provider and a service provider. EmpowerID functions as both an identity provider and a service provider.

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.





SAML

SAML is an XML-based protocol that provides a flexible means by which users can engage in identity transactions and organizations can exchange identity data. It is the protocol of choice among government agencies, major corporations, and service providers wishing to exchange identity data for the purpose of SSO between different security domains.

In SAML transactions, identity providers make an assertion about an authenticated user's identity, encrypt and sign the assertion, and pass that data to a service provider. The service provider receives the assertion, validates and decrypts it, and makes an access control decision, granting or denying access to services as is appropriate. Although there are a number of steps involved with these transactions, after an identity is federated, the process remains fairly invisible to the user. They simply authenticate once and navigate to the desired applications.

SAML 2.0 standards require that SAML-based identity transactions be comprised of a number of functional layers. These layers frame the SAML, providing descriptive and declarative information necessary for a federating partner to consume it. These layers include assertions, bindings, profiles, and protocols.

  • Assertions - SAML Assertions are the authentication data generated by an IdP in response to an authentication event. These statements identify the user, the authenticating IdP, and any circumstantial data surrounding the authentication event such as time/date stamps, audience restrictions, and expiration notices. SAML assertions are digitally signed by IdPs to ensure the integrity of the assertions.

  • SAML Bindings - SAML bindings describe the communication protocols used to transport SAML messages between identity providers and service providers. EmpowerID supports SOAP, HTTP Redirect, and HTTP POST.

  • SAML Protocol - SAML protocols define how identity providers and service providers are to process the SAML data they exchange with one another.

  • SAML Profiles - SAML profiles provide the underlying framework that defines the combinations of assertions, bindings, and protocols for implementing transactions. The most popular profile is browser-based SSO, which allows users to Single Sign-On from any standard Web browser.

OAuth  2.0

OAuth 2.0 is an open standard authorization framework that enables secure data sharing among applications without requiring users to divulge their credentials, such as login information or passwords. Through OAuth 2.0, users can grant restricted access of their resources to a third-party as well as safely access resources of a third-party themselves. OAuth 2.0 is the standard for API delegation with built-in support for mobile devices, websites, set-top boxes, and desktop applications.

By giving the user security tokens to hand out, instead of requiring login or password information (or other secure credentials), OAuth 2.0 allows for securely defined information sharing. For example, each token may grant access to a specific resource (e.g. a video inside a specific folder) for a pre-determined duration (e.g. for the following 24 hrs).

EmpowerID itself uses OAuth 2.0 to keep APIs used by enterprise customers secure while enterprises use it to protect the APIs they themselves offer to third-parties.

OpenID Connect

OpenID Connect (OIDC) is an identity protocol that sits on top of OAuth 2.0 for the purpose of authenticating users before authorizing them to access protected APIs. In OIDC, the mechanism for this is a security token, called an “IT Token.” The ID Token contains claims about the user delivered to a client in JSON Web Token (JWT) format.

OpenID Connect allows users to select from any number of IdPs to present the desired digital identities to a service provider each time they engage in an identity transaction. As long as the SP accepts OIDC authentication and can link the digital identity to an identity it recognizes, that user will be granted access to any authorized resources, regardless of the digital identity provided.

WS-Trust and WS-Federation

WS-Trust, short for "Web Services Trust Language," is an important specification that provides extensions to WS-Security (Web Services Security), a protocol used for securing SOAP (Simple Object Access Protocol) communication. "WS-" is a prefix used to indicate specifications associated with Web Services and there exist many WS* standards including WS-Addressing, WS- Discovery, WS-Federation, WS-Policy, WS-Security, and WS-Trust. WS-Trust deals with managing software security tokens, examples of which include SAML tokens and UsernameTokens. Specifically, WS-Trust defines protocols to issue, renew and cancel WS-Security tokens, thereby enabling secure message exchange through Web Services.

A Security Token Service (STS) is a key concept in WS-Trust as it is the software responsible for issuing and converting tokens. The STS converts locally issued tokens (in the WS-Trust model, a SAML assertion is a type of token) into a format (e.g., SAML) that can be shared with Web services providers and also for converting incoming tokens into a format that can be used by local applications.

WS-Federation describes the management and brokering of trust relationships and security token exchange across Web services and organizational boundaries. WS-Federation is a part of the larger WS-Security framework and an extension to the functionality of WS-Trust. For example, WS-Federation builds on the Security Token Service (STS) model defined in WS-Trust by providing mechanisms that facilitate interactions. Through WS-Federation protocol extensions, WS-Trust enables integrating attribute, pseudonym, and claims authorization services with Security Token Services.

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 the Login 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.

SAML 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.

In EmpowerID, the flow between identity management partners depends on the creation of SSO connections framed with the particular federated identity model employed by a federated partner.

SP-Initiated for Unmapped Identities

This scenario describes how to link an EmpowerID identity to an identity provided by a secondary IdP (non-EmpowerID), where the following are true:

  • The user has a Person object in EmpowerID

  • The IdP account does not exist in EmpowerID

  • The IdP account is not linked to an EmpowerID Person

In this scenario, EmpowerID has been configured with an SSO Connection for Google as an IdP, allowing users to access resources in EmpowerID using their Google identities. An EmpowerID Person, "BRubble," has an identity (user account) with Google that she would like to use to log in to EmpowerID.

To begin the transaction, BRubble navigates to the EmpowerID Web application (SP) for her organization and from her browser clicks on the Google login tile on the EmpowerID IdP Login screen. In response, EmpowerID redirects her browser to Google with a SAML request for authentication. Google responds to the request by asking BRubble to authenticate using her Google credentials. After successfully authenticating, Google generates a federation assertion, signs and encrypts it and redirects BRubble's browser back to the EmpowerID IdP page with the authentication data. EmpowerID receives this authentication data, decrypts it, and verifies the signature to ensure the integrity of the data. After verifying the data, EmpowerID initiates the Login Workflow to validate the session. The Login Workflow determines that the Google account does not have an EmpowerID Person joined to it and executes the FirstLoginRequestAccountAndPersonActivity activity. This activity displays a form to BRubble asking if she has an EmpowerID Login. Depending on how she answers, the activity will direct the Login Workflow in one of two ways:

  1. The answer is "No." (I don't have an EmpowerID Login.) - If the user does not have an EmpowerID Login, EmpowerID gives her the opportunity to request an account. If she requests the account, EmpowerID initiates an Account Request workflow and exits the Login Workflow. The user will not be able to log in until her account request is approved.

  2. The answer is "Yes." (I have an EmpowerID Login.) - If the user has an EmpowerID Login, EmpowerID asks her to submit the username or primary email address associated with her EmpowerID Person. EmpowerID then searches for that Person.

    1. If no matching Person is found, the user is allowed to resubmit these attributes up to four more times (for a total of five attempts). If no matching Person is found after five attempts, the Login Workflow ends and the user cannot log in.

    2. If a matching Person is found, EmpowerID sends a security code (one-time password) to the primary and secondary email addresses on the user's EmpowerID Person object or as a text message to the user's mobile device. The user is then presented with a form to enter the security code. If the user submits a correct security code, EmpowerID joins the account to the Person. If the user submits an incorrect security code, EmpowerID allows them two more attempts for a total of three tries. If after the third attempt the code cannot be validated, the Login Workflow exits and the user cannot log in with the Google account.

Since BRubble has an EmpowerID Person, she submits her EmpowerID Login. Since she has not previously used her Google account to log in to EmpowerID, EmpowerID emails her a security code to confirm her desire to federate her Google identity with her EmpowerID identity. BRubble submits the security code to EmpowerID via her browser. EmpowerID validates the security code, adds the Google account to the Google account store in EmpowerID and joins the Google account to BRubble, the EmpowerID Person.

After joining the account to BRubble, EmpowerID allows BRubble to login.





The sequence for this transaction is as follows:

  1. From her browser, BRubble navigates to the EmpowerID Web application for her organization.

  2. The EmpowerID Web application (SP) directs her to the EmpowerID IdP login screen. BRubble's organization has set up SSO Connections to allow their users to log in to the EmpowerID application using either their EmpowerID credentials (username and password) or Google accounts.

  3. BRubble opts to log in using her Google account by clicking on the Google login tile on the EmpowerID login screen. EmpowerID responds by redirecting her browser to Google with a SAML request for authentication.

  4. Google asks BRubble to authenticate with her Google identity. Upon successfully authenticating, Google generates a federation assertion, signs and encrypts it, and redirects BRubble's browser back to EmpowerID.

  5. EmpowerID decrypts the assertion, verifies the signature and initiates the EmpowerID Login Workflow to validate the login. The EmpowerID Login Workflow determines that the Google account does not belong to an EmpowerID Person.

  6. EmpowerID asks BRubble to confirm her EmpowerID identity and then sends a security code to her corporate email to verify her desire to federate her EmpowerID and Google identities.

  7. BRubble verifies her desire to federate the two identities by submitting the security code to EmpowerID via her browser.

  8. EmpowerID adds the Google account to the Google account store in EmpowerID and joins the Google account to BRubble's EmpowerID Person object.

  9. The Login Workflow exits and returns the process to the EmpowerID IdP.

  10. The EmpowerID IdP generates a token defining the amount of access to EmpowerID resources to which BRubble is authorized and passes that token to the EmpowerID SP.

  11. The EmpowerID SP grants BRubble access to EmpowerID resources.

SP-Initiated for Mapped Identities

This scenario describes the flow for logging in to EmpowerID using an identity supplied from a non-EmpowerID IdP. In the scenario, the following are true:

  • The user has a Person object in EmpowerID

  • The IdP account exists in EmpowerID

  • The IdP account is linked to an EmpowerID Person

In this scenario, EmpowerID has been configured with an SSO Connection for Google as an IdP, allowing users to access resources in EmpowerID using their Google identities. An EmpowerID Person, "BRubble," has an identity (user account) with Google that she would like to use to log in to EmpowerID. Since these identities are already linked together in EmpowerID, BRubble can simply click the Google Login tile on the Login page of the EmpowerID application, authenticate with Google from her browser and then work in EmpowerID.

To begin the transaction, BRubble navigates to the EmpowerID Web application for her organization and from her browser clicks on the Google login tile on the EmpowerID Login screen. In response, EmpowerID redirects her browser to Google with a SAML request for authentication. Google responds to the request by asking BRubble to authenticate using her Google credentials. After successfully authenticating, Google generates a federation assertion, signs and encrypts it and redirects BRubble's browser back to EmpowerID with the authentication data. EmpowerID receives the authentication data, decrypts it, and verifies the signature to ensure the integrity of the data. After verifying the data, EmpowerID checks the EmpowerID Identity Warehouse and determines that the Google account belongs to BRubble and then generates a token defining the amount of access to EmpowerID resources BRubble is authorized to consume and passes that token to the EmpowerID SP, which grants her access.





The sequence for this transaction is as follows:

  1. From her browser, BRubble navigates to the EmpowerID Web application for her organization.

  2. The EmpowerID Web application (SP) directs her to the EmpowerID IdP login screen. BRubble's organization has set up SSO Connections to allow their users to log in to the EmpowerID application using either their EmpowerID credentials (username and password) or Google accounts.

  3. BRubble opts to log in using her Google account by clicking on the Google login tile on the EmpowerID login screen. EmpowerID responds by redirecting her browser to Google with a SAML request for authentication.

  4. Google asks BRubble to authenticate with her Google identity. Upon successfully authenticating, Google generates a federation assertion, signs and encrypts it, and redirects BRubble's browser back to EmpowerID.

  5. EmpowerID decrypts the assertion, verifies the signature and checks the EmpowerID Identity Warehouse to see if the account belongs to BRubble.

  6. The EmpowerID Identity Warehouse confirms that the Google account belongs to BRubble and returns the process to the EmpowerID IdP.

  7. EmpowerID generates a token defining the amount of access to EmpowerID resources to which BRubble is authorized and passes that token to the EmpowerID SP.

  8. The EmpowerID SP grants BRubble access to her EmpowerID resources.

 

SP-Initiated for (non-EmpowerID) Unmapped Identities

This scenario describes the flow for linking an EmpowerID identity to an identity that exists in an external SP (Salesforce). In this scenario the following conditions are true:

  • The user's organization has a trust relationship with the SP (EmpowerID is configured with an SSO Connection for the SP)

  • The user has an identity with the SP

  • The user has a Person object in EmpowerID

  • The SP account does not exist in EmpowerID

  • The SP account is not linked to an EmpowerID Person

To begin the transaction, BRubble, the EmpowerID Person, navigates to the EmpowerID Web application (SP) for her organization, which directs her to the Login page for the EmpowerID IdP where BRubble submits her EmpowerID credentials. The EmpowerID Login Workflow validates her credentials, exits, and returns the process to the EmpowerID IdP. The EmpowerID IdP generates a token defining the resources BRubble is authorized to access and passes that token to the EmpowerID SP. The EmpowerID SP allows BRubble to access her EmpowerID resources.

BRubble then navigates to the SSO Application Catalog in EmpowerID and clicks on the link for Salesforce. This initiates the ClaimSSOAccount workflow, which allows users to register accounts they have with external service providers in EmpowerID, linking those accounts to their EmpowerID Person. BRubble enters her login for Salesforce and submits her request. (Logins must be valid email addresses for the user's identity at the service provider.) The ClaimSSOAccount workflow verifies that an account with that login for Salesforce does not already exist in EmpowerID and then sends a security code (one-time password) to the user's email address at Salesforce. BRubble retrieves the security code from her Salesforce email account and submits it to EmpowerID. If the security code is correct, EmpowerID joins the account to the Person and redirects her browser to Salesforce with a SAML assertion of her identity. Salesforce consumes the assertion and based on the trust relationship it has with EmpowerID allows BRubble in.





The sequence for this transaction is as follows:

  1. From her browser, BRubble navigates to the EmpowerID Web application for her organization.

  2. The EmpowerID Web application (SP) directs her to the EmpowerID IdP login screen.

  3. BRubble logs in with her EmpowerID credentials.

  4. The Login Workflow validates the session.

  5. The EmpowerID IdP generates a token defining the amount of access to EmpowerID resources to which BRubble is authorized and passes that token to the EmpowerID SP.

  6. The EmpowerID SP grants BRubble access to her EmpowerID resources. She navigates to the SSO Application Catalog, where she clicks on the Salesforce link to request her identity there be federated with her identity at EmpowerID.

  7. This initiates the Register Account Workflow. BRubble enters her login for Salesforce and submits her request. (Logins must be valid email addresses for the user's identity at the service provider.)

  8. The Register Account Workflow sends a security code to the email account entered into the workflow form by BRubble. BRubble verifies her desire to federate the two identities by submitting the security code to EmpowerID via her browser.

  9. EmpowerID adds the Salesforce account to the Salesforce account store in EmpowerID and joins the Salesforce account to BRubble's EmpowerID Person object.

  10. The EmpowerID IdP redirects BRubble's browser to Salesforce with an assertion of her identity.

  11. Salesforce consumes the assertion and allows BRubble in.

 

SP-Initiated for (non-EmpowerID) Mapped Identities

This scenario describes the flow for logging in to a service provider (Salesforce) using EmpowerID as the identity provider where the following conditions are true:

  • The user's organization has a trust relationship with the SP

  • The user has an identity with the SP

  • The user has a Person object in EmpowerID

  • EmpowerID is configured with an SSO Connection for the SP

  • The SP account exists in EmpowerID

  • The SP account is linked to the EmpowerID Person

To begin the transaction, BRubble navigates from her browser to the Salesforce Web application for her organization, using the URL supplied by that organization. This URL is a concatenation of the FQDN for the EmpowerID web server in her environment and the Target URL of the Salesforce SSO Connection created in EmpowerID. This directs BRubble's browser to the Login page of the EmpowerID IdP, where she can authenticate using any identity provider trusted by EmpowerID. In this case BRubble simply authenticates with her EmpowerID credentials. TheEmpowerID Identity Warehouse verifies her identity and the EmpowerID IdP generates an assertion of her identity, signs and encrypts it, and then passes the assertion back to Salesforce with a form post redirect to Salesforce's assertion consumer service. In turn, Salesforce verifies the integrity of the response and links BRubble's identity in Salesforce with her identity at EmpowerID. From this point forward, each time BRubble chooses to authenticate to Salesforce with her EmpowerID identity, Salesforce will grant her access to all the resources to which she is entitled, just as if she had directly logged in.





The sequence for this transaction is as follows:

  1. From her browser, BRubble navigates to the Salesforce Web application for her organization.

  2. This directs her to the EmpowerID IdP login screen, where BRubble enters her EmpowerID credentials.

  3. The EmpowerID IdP initiates the Login Workflow to verify the credentials submitted by BRubble.

  4. The EmpowerID Identity Warehouse validates the credentials and exits, returning the process to the EmpowerID IdP.

  5. The EmpowerID IdP generates a federation assertion, signs and encrypts it, and redirects BRubble's browser to Salesforce.

  6. Salesforce consumes the assertion and based on the trust relationship it has with EmpowerID allows BRubble in.

 

SP-Initiated (non-EmpowerID) for Secondary IdP Identities Mapped to an EmpowerID Person

This scenario describes the flow for logging in to a service provider (Salesforce) from EmpowerID using a secondary identity provider (Google) trusted by EmpowerID. In this scenario the following conditions are true:

  • The user's organization has a trust relationship with both the SP and the IdP (EmpowerID is configured with SSO connections for both the SP and the IdP)

  • The user has an identity with both the SP and the IdP

  • The user has a Person object in EmpowerID

  • Both the SP and IdP accounts for the user exist in EmpowerID

  • Both the SP and IdP accounts are linked to the EmpowerID Person

To begin the transaction, BRubble navigates from her browser to the Salesforce Web application for her organization, using the URL supplied by that organization. This URL is a concatenation of the FQDN for the EmpowerID web server in her environment and the Target URL of the Salesforce SSO Connection created in EmpowerID. This directs BRubble's browser to the Login page of the EmpowerID IdP, where she opts to use her Google account by clicking on the Google login tile on the EmpowerID Login screen. In response, EmpowerID redirects her browser to Google with a SAML request for authentication. Google responds to the request by asking BRubble to authenticate using her Google credentials. After successfully authenticating, Google generates a federation assertion, signs and encrypts it and redirects BRubble's browser back to EmpowerID with the authentication data. EmpowerID receives the authentication data, decrypts it, and verifies the signature to ensure the integrity of the data. After verifying the data, EmpowerID checks the EmpowerID Identity Warehouse to validate the session. The EmpowerID Identity Warehouse verifies that the Google account belongs to BRubble and exits, returning the process to the EmpowerID Idp. The EmpowerID IdP generates an assertion of her identity, signs and encrypts it, and then passes the assertion to Salesforce with a form post redirect to Salesforce's assertion consumer service. In turn, Salesforce verifies the integrity of the response and based on the trust relationship it has with EmpowerID allows BRubble in.



The sequence for this transaction is as follows:

  1. From her browser, BRubble navigates to the Salesforce Web application for her organization.

  2. This directs her to the EmpowerID IdP login screen, where BRubble opts to log in using her Google account by clicking on the Google login tile on the EmpowerID login screen.

  3. EmpowerID responds by redirecting her browser to Google with a SAML request for authentication.

  4. Google asks BRubble to authenticate with her Google identity. Upon successfully authenticating, Google generates a federation assertion, signs and encrypts it, and redirects BRubble's browser back to EmpowerID.

  5. EmpowerID decrypts the assertion, verifies the signature and checks the EmpowerID Identity Warehouse to validate the login.

  6. The EmpowerID Identity Warehouse confirms that the Google account belongs to BRubble and exits, returning the process to the EmpowerID IdP.

  7. The EmpowerID IdP generates a federation assertion, signs and encrypts it, and redirects BRubble's browser to Salesforce.

  8. Salesforce consumes the assertion and based on the trust relationship it has with EmpowerID allows BRubble in.

 

SP-Initiated for Unmapped SP and Secondary IdP Identities

This scenario describes the flow for logging in to a service provider (Salesforce) from EmpowerID using a secondary identity provider (Google) trusted by EmpowerID. In this scenario the following conditions are true:

  • The user's organization has a trust relationship with both the SP and the IdP (EmpowerID is configured with SSO connections for both the SP and the IdP)

  • The user has an identity with both the SP and the IdP

  • The user has a Person object in EmpowerID

  • Neither the IdP nor the SP accounts for exist in EmpowerID

  • Neither the IdP nor the SP accounts are linked to the EmpowerID Person

To begin the transaction, BRubble, the EmpowerID Person, navigates to the EmpowerID Web application (SP) for her organization and from her browser clicks on the Google login tile on the EmpowerID IdP Login screen. In response, EmpowerID redirects her browser to Google with a SAML request for authentication. Google responds to the request by asking BRubble to authenticate using her Google credentials. After successfully authenticating, Google generates a federation assertion, signs and encrypts it and redirects BRubble's browser back to the EmpowerID IdP page with the authentication data. EmpowerID receives this authentication data, decrypts it, and verifies the signature to ensure the integrity of the data. After verifying the data, EmpowerID initiates the Login Workflow to validate the session. The Login Workflow determines that the Google account does not have an EmpowerID Person joined to it and executes the FirstLoginRequestAccountAndPersonActivity activity. This activity displays a form to BRubble asking if she has an EmpowerID Login. Depending on how she answers, the activity will direct the Login Workflow in one of two ways:

  1. The answer is "No." (I don't have an EmpowerID Login.) - If the user does not have an EmpowerID Login, EmpowerID gives her the opportunity to request an account. If she requests the account, EmpowerID initiates an Account Request workflow and exits the Login Workflow. The user will not be able to log in until her account request is approved.

  2. The answer is "Yes." (I have an EmpowerID Login.) - If the user has an EmpowerID Login, EmpowerID asks her to submit the username or primary email address associated with her EmpowerID Person. EmpowerID then searches for that Person.

    1. If no matching Person is found, the user is allowed to resubmit these attributes up to four more times (for a total of five attempts). If no matching Person is found after five attempts, the Login Workflow ends and the user cannot log in.

    2. If a matching Person is found, EmpowerID sends a security code (one-time password) to the primary and secondary email addresses on the user's EmpowerID Person object or as a text message to the user's mobile device. The user is then presented with a form to enter the security code. If the user submits a correct security code, EmpowerID joins the account to the Person. If the user submits an incorrect security code, EmpowerID allows them two more attempts for a total of three tries. If after the third attempt the code cannot be validated, the Login Workflow exits and the user cannot log in with the Google account.

Since BRubble has an EmpowerID Person, she submits her EmpowerID Login. Since she has not previously used her Google account to log in to EmpowerID, EmpowerID emails her a security code to confirm her desire to federate her Google identity with her EmpowerID identity. BRubble submits the security code to EmpowerID via her browser. EmpowerID validates the security code, adds the Google account to the Google account store in EmpowerID and joins the Google account to BRubble, the EmpowerID Person.

After joining the account to BRubble, EmpowerID allows BRubble to login. BRubble then navigates to the SSO Application Catalog in EmpowerID and clicks on the link for Salesforce. This initiates the ClaimSSOAccount workflow, which allows users to register accounts they have with external service providers in EmpowerID, linking those accounts to their EmpowerID Person. BRubble enters her login for Salesforce and submits her request. (Logins must be valid email addresses for the user's identity at the service provider.) The ClaimSSOAccount workflow verifies that an account with that login for Salesforce does not already exist in EmpowerID and then sends a security code (one-time password) to the user's email address at Salesforce. BRubble retrieves the security code from her Salesforce email account and submits it to EmpowerID. If the security code is correct, EmpowerID joins the account to the Person and redirects her browser to Salesforce with a SAML assertion of her identity. Salesforce consumes the assertion and based on the trust relationship it has with EmpowerID allows BRubble in.





The sequence for this transaction is as follows:

  1. From her browser, BRubble navigates to the EmpowerID Web application for her organization.

  2. The EmpowerID Web application (SP) directs her to the EmpowerID IdP login screen. BRubble's organization has set up SSO Connections to allow their users to log in to the EmpowerID application using either their EmpowerID credentials (username and password) or Google accounts.

  3. BRubble opts to log in using her Google account by clicking on the Google login tile on the EmpowerID login screen. EmpowerID responds by redirecting her browser to Google with a SAML request for authentication.

  4. Google asks BRubble to authenticate with her Google identity. Upon successfully authenticating, Google generates a federation assertion, signs and encrypts it, and redirects BRubble's browser back to EmpowerID.

  5. EmpowerID decrypts the assertion, verifies the signature and initiates the EmpowerID Login Workflow to validate the login. The EmpowerID Login Workflow determines that the Google account does not belong to an EmpowerID Person.

  6. EmpowerID asks BRubble to confirm her EmpowerID identity and then sends a security code to her corporate email to verify her desire to federate her EmpowerID and Google identities.

  7. BRubble verifies her desire to federate the two identities by submitting the security code to EmpowerID via her browser. EmpowerID adds the Google account to the Google account store in EmpowerID and joins the Google account to BRubble's EmpowerID Person object.

  8. The Login Workflow exits and returns the process to the EmpowerID IdP.

  9. The EmpowerID IdP generates a token defining the amount of access to EmpowerID resources to which BRubble is authorized and passes that token to the EmpowerID SP.

  10. The EmpowerID SP grants BRubble access to EmpowerID resources. She navigates to the SSO Application Catalog and clicks on the Salesforce link to request her identity there be federated with her identity at EmpowerID.

  11. This initiates the Register Account Workflow. BRubble enters her login for Salesforce and submits her request. (Logins must be valid email addresses for the user's identity at the service provider.)

  12. The Register Account Workflow sends a security code to the SP email account entered into the workflow form by BRubble. BRubble verifies her desire to federate the two identities by submitting the security code to EmpowerID via her browser.

  13. EmpowerID adds the Salesforce account to the Salesforce account store in EmpowerID and joins the Salesforce account to BRubble's EmpowerID Person object.

  14. The Register Account Workflow exits and returns the process to the EmpowerID IdP.

  15. The EmpowerID IdP redirects BRubble's browser to Salesforce with an assertion of her identity.

  16. Salesforce consumes the assertion and allows BRubble in.

SP-Initiated (non-EmpowerID) for Unmapped SP and Secondary IdP Identities

This scenario describes the flow for logging in to a service provider (Salesforce) from EmpowerID using a secondary identity provider (Google) trusted by EmpowerID. In this scenario the following conditions are true:

  • The user's organization has a trust relationship with both the SP and the IdP (EmpowerID is configured with SSO connections for both the SP and the IdP)

  • The user has an identity with both the SP and the IdP

  • The user has a Person object in EmpowerID

  • Neither the IdP nor the SP accounts for exist in EmpowerID

  • Neither the IdP nor the SP accounts are linked to the EmpowerID Person

To begin the transaction, BRubble, the EmpowerID Person, navigates to the EmpowerID Web application (SP) for her organization and from her browser clicks on the Google login tile on the EmpowerID IdP Login screen. In response, EmpowerID redirects her browser to Google with a SAML request for authentication. Google responds to the request by asking BRubble to authenticate using her Google credentials. After successfully authenticating, Google generates a federation assertion, signs and encrypts it and redirects BRubble's browser back to the EmpowerID IdP page with the authentication data. EmpowerID receives this authentication data, decrypts it, and verifies the signature to ensure the integrity of the data. After verifying the data, EmpowerID initiates the Login Workflow to validate the session. The Login Workflow determines that the Google account does not have an EmpowerID Person joined to it and executes the FirstLoginRequestAccountAndPersonActivity activity. This activity displays a form to BRubble asking if she has an EmpowerID Login. Depending on how she answers, the activity will direct the Login Workflow in one of two ways:

  1. The answer is "No." (I don't have an EmpowerID Login.) - If the user does not have an EmpowerID Login, EmpowerID gives her the opportunity to request an account. If she requests the account, EmpowerID initiates an Account Request workflow and exits the Login Workflow. The user will not be able to log in until her account request is approved.

  2. The answer is "Yes." (I have an EmpowerID Login.) - If the user has an EmpowerID Login, EmpowerID asks her to submit the username or primary email address associated with her EmpowerID Person. EmpowerID then searches for that Person.

    1. If no matching Person is found, the user is allowed to resubmit these attributes up to four more times (for a total of five attempts). If no matching Person is found after five attempts, the Login Workflow ends and the user cannot log in.

    2. If a matching Person is found, EmpowerID sends a security code (one-time password) to the primary and secondary email addresses on the user's EmpowerID Person object or as a text message to the user's mobile device. The user is then presented with a form to enter the security code. If the user submits a correct security code, EmpowerID joins the account to the Person. If the user submits an incorrect security code, EmpowerID allows them two more attempts for a total of three tries. If after the third attempt the code cannot be validated, the Login Workflow exits and the user cannot log in with the Google account.

Since BRubble has an EmpowerID Person, she submits her EmpowerID Login. Since she has not previously used her Google account to log in to EmpowerID, EmpowerID emails her a security code to confirm her desire to federate her Google identity with her EmpowerID identity. BRubble submits the security code to EmpowerID via her browser. EmpowerID validates the security code, adds the Google account to the Google account store in EmpowerID and joins the Google account to BRubble, the EmpowerID Person.

After joining the account to BRubble, EmpowerID allows BRubble to login. BRubble then navigates to the SSO Application Catalog in EmpowerID and clicks on the link for Salesforce. This initiates the ClaimSSOAccount workflow, which allows users to register accounts they have with external service providers in EmpowerID, linking those accounts to their EmpowerID Person. BRubble enters her login for Salesforce and submits her request. (Logins must be valid email addresses for the user's identity at the service provider.) The ClaimSSOAccount workflow verifies that an account with that login for Salesforce does not already exist in EmpowerID and then sends a security code (one-time password) to the user's email address at Salesforce. BRubble retrieves the security code from her Salesforce email account and submits it to EmpowerID. If the security code is correct, EmpowerID joins the account to the Person and redirects her browser to Salesforce with a SAML assertion of her identity. Salesforce consumes the assertion and based on the trust relationship it has with EmpowerID allows BRubble in.





The sequence for this transaction is as follows:

  1. From her browser, BRubble navigates to the EmpowerID Web application for her organization.

  2. The EmpowerID Web application (SP) directs her to the EmpowerID IdP login screen. BRubble's organization has set up SSO Connections to allow their users to log in to the EmpowerID application using either their EmpowerID credentials (username and password) or Google accounts.

  3. BRubble opts to log in using her Google account by clicking on the Google login tile on the EmpowerID login screen. EmpowerID responds by redirecting her browser to Google with a SAML request for authentication.

  4. Google asks BRubble to authenticate with her Google identity. Upon successfully authenticating, Google generates a federation assertion, signs and encrypts it, and redirects BRubble's browser back to EmpowerID.

  5. EmpowerID decrypts the assertion, verifies the signature and initiates the EmpowerID Login Workflow to validate the login. The EmpowerID Login Workflow determines that the Google account does not belong to an EmpowerID Person.

  6. EmpowerID asks BRubble to confirm her EmpowerID identity and then sends a security code to her corporate email to verify her desire to federate her EmpowerID and Google identities.

  7. BRubble verifies her desire to federate the two identities by submitting the security code to EmpowerID via her browser. EmpowerID adds the Google account to the Google account store in EmpowerID and joins the Google account to BRubble's EmpowerID Person object.

  8. The Login Workflow exits and returns the process to the EmpowerID IdP.

  9. The EmpowerID IdP generates a token defining the amount of access to EmpowerID resources to which BRubble is authorized and passes that token to the EmpowerID SP.

  10. The EmpowerID SP grants BRubble access to EmpowerID resources. She navigates to the SSO Application Catalog and clicks on the Salesforce link to request her identity there be federated with her identity at EmpowerID.

  11. This initiates the Register Account Workflow. BRubble enters her login for Salesforce and submits her request. (Logins must be valid email addresses for the user's identity at the service provider.)

  12. The Register Account Workflow sends a security code to the SP email account entered into the workflow form by BRubble. BRubble verifies her desire to federate the two identities by submitting the security code to EmpowerID via her browser.

  13. EmpowerID adds the Salesforce account to the Salesforce account store in EmpowerID and joins the Salesforce account to BRubble's EmpowerID Person object.

  14. The Register Account Workflow exits and returns the process to the EmpowerID IdP.

  15. The EmpowerID IdP redirects BRubble's browser to Salesforce with an assertion of her identity.

  16. Salesforce consumes the assertion and allows BRubble in.

IN THIS ARTICLE