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: - 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.
- 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.
- 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.
- 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: - From her browser, BRubble navigates to the EmpowerID Web application for her organization.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- The Login Workflow exits and returns the process to the EmpowerID IdP.
- 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.
- The EmpowerID SP grants BRubble access to EmpowerID resources.
|
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: - From her browser, BRubble navigates to the EmpowerID Web application for her organization.
- 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.
- 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.
- 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.
- EmpowerID decrypts the assertion, verifies the signature and checks the EmpowerID Identity Warehouse to see if the account belongs to BRubble.
- The EmpowerID Identity Warehouse confirms that the Google account belongs to BRubble and returns the process to the EmpowerID IdP.
- 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.
- The EmpowerID SP grants BRubble access to her EmpowerID resources.
|
This scenario describes the flow for linking an EmpowerID identity to an identity that exists in an external SP (Salesforce.com). 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.com. 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.com 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.com does not already exist in EmpowerID and then sends a security code (one-time password) to the user's email address at Salesforce.com. BRubble retrieves the security code from her Salesforce.com 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.com with a SAML assertion of her identity. Salesforce.com consumes the assertion and based on the trust relationship it has with EmpowerID allows BRubble in.
The sequence for this transaction is as follows: - From her browser, BRubble navigates to the EmpowerID Web application for her organization.
- The EmpowerID Web application (SP) directs her to the EmpowerID IdP login screen.
- BRubble logs in with her EmpowerID credentials.
- The Login Workflow validates the session.
- 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.
- The EmpowerID SP grants BRubble access to her EmpowerID resources. She navigates to the SSO Application Catalog, where she clicks on the Salesforce.com link to request her identity there be federated with her identity at EmpowerID.
- This initiates the Register Account Workflow. BRubble enters her login for Salesforce.com and submits her request. (Logins must be valid email addresses for the user's identity at the service provider.)
- 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.
- EmpowerID adds the Salesforce.com account to the Salesforce.com account store in EmpowerID and joins the Salesforce.com account to BRubble's EmpowerID Person object.
- The EmpowerID IdP redirects BRubble's browser to Salesforce.com with an assertion of her identity.
- Salesforce.com consumes the assertion and allows BRubble in.
|
This scenario describes the flow for logging in to a service provider (Salesforce.com) 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.com 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.com 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.com with a form post redirect to Salesforce.com's assertion consumer service. In turn, Salesforce.com verifies the integrity of the response and links BRubble's identity in Salesforce.com with her identity at EmpowerID. From this point forward, each time BRubble chooses to authenticate to Salesforce.com with her EmpowerID identity, Salesforce.com 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: - From her browser, BRubble navigates to the Salesforce.com Web application for her organization.
- This directs her to the EmpowerID IdP login screen, where BRubble enters her EmpowerID credentials.
- The EmpowerID IdP initiates the Login Workflow to verify the credentials submitted by BRubble.
- The EmpowerID Identity Warehouse validates the credentials and exits, returning the process to the EmpowerID IdP.
- The EmpowerID IdP generates a federation assertion, signs and encrypts it, and redirects BRubble's browser to Salesforce.com.
- Salesforce.com consumes the assertion and based on the trust relationship it has with EmpowerID allows BRubble in.
|
This scenario describes the flow for logging in to a service provider (Salesforce.com) 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.com 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.com 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.com with a form post redirect to Salesforce.com's assertion consumer service. In turn, Salesforce.com 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: - From her browser, BRubble navigates to the Salesforce.com Web application for her organization.
- 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.
- EmpowerID responds by redirecting her browser to Google with a SAML request for authentication.
- 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.
- EmpowerID decrypts the assertion, verifies the signature and checks the EmpowerID Identity Warehouse to validate the login.
- The EmpowerID Identity Warehouse confirms that the Google account belongs to BRubble and exits, returning the process to the EmpowerID IdP.
- The EmpowerID IdP generates a federation assertion, signs and encrypts it, and redirects BRubble's browser to Salesforce.com.
- Salesforce.com consumes the assertion and based on the trust relationship it has with EmpowerID allows BRubble in.
|
This scenario describes the flow for logging in to a service provider (Salesforce.com) 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: - 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.
- 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.
- 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.
- 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.com. 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.com 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.com does not already exist in EmpowerID and then sends a security code (one-time password) to the user's email address at Salesforce.com. BRubble retrieves the security code from her Salesforce.com 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.com with a SAML assertion of her identity. Salesforce.com consumes the assertion and based on the trust relationship it has with EmpowerID allows BRubble in.
The sequence for this transaction is as follows: - From her browser, BRubble navigates to the EmpowerID Web application for her organization.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- The Login Workflow exits and returns the process to the EmpowerID IdP.
- 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.
- The EmpowerID SP grants BRubble access to EmpowerID resources. She navigates to the SSO Application Catalog and clicks on the Salesforce.com link to request her identity there be federated with her identity at EmpowerID.
- This initiates the Register Account Workflow. BRubble enters her login for Salesforce.com and submits her request. (Logins must be valid email addresses for the user's identity at the service provider.)
- 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.
- EmpowerID adds the Salesforce.com account to the Salesforce.com account store in EmpowerID and joins the Salesforce.com account to BRubble's EmpowerID Person object.
- The Register Account Workflow exits and returns the process to the EmpowerID IdP.
- The EmpowerID IdP redirects BRubble's browser to Salesforce.com with an assertion of her identity.
- Salesforce.com consumes the assertion and allows BRubble in.
|
|