How SSO Works

This section explains how a user retrieves a specific resource of an SSO system. This process requires from an SP and IdP to perform specific actions (within their functions) in a specific order. You must reorganize your SP logic to match the communication model.

To grant a user access to a specific resource of an SP registered in IdP, the following sequence of steps is performed:

1. The user requests the resource.
2. The SP checks if there is an opened local session for the user
   1. If the session exists, the SP checks if the user is authorized to access the resource. If the user is authorized, the access is granted. [end]
   2. If the session does not exist, [to step 3].
3. SP requests the user authentication from IdP by sending <AuthnRequest> SAML message.
4. IdP checks if a global session is opened for the user.
   1. If the session exists,[to step 8]
   2. If the session does not exist, [to step 5].
5. IdP sends specific parameters to the SP to render the challenging for credentials IdP user interface. The SP receives the parameters and displays the user interface to the user. (If the user comes to step 5 from step 8c, IdP user interface parameter message_id = SP_CREDS_REQUIRED)
6. The user enters account credentials and submits the form or clicks cancel.
   1. If the form is submitted, the SP sends the credentials to IdP. [to step 7]
   2. If the form is cancelled, IdP responds to the SP with message_id = AUTH_FAILED (see the IdP Interfaces>Front Channel Interface>Authentication-related Operations>Challenging for Credentials section of the Specification). The SP displays an authentication error message to the user agent. [end]
7. IdP verifies the credentials. If the credentials correspond to a global account, IdP verifies them against its database. If the credentials do not match any global account, IdP queries the SP to verify the credentials. In latter case, IdP uses proxied authentication request service.
   1. If the credentials are successfully verified, IdP creates a global session for the user. [to step 8]
   2. If credentials verification fails, [to step 5].
8. IdP checks what local accounts can be used to log in to the SP.
   1. If the user can use a single account, IdP responds to the SP with <Response> SAML message containing specific information about the user. The SP creates a local session for the user. [to step 2a]

      Note: This branch is chosen only in two cases:

      * If the user specified global account credentials, and the FI corresponding to the global account includes ID of a single local account at the SP.

      * If the user specified credentials of a local account at the SP.

   2. If the user can use more than one local account, IdP fetches the list of login names/UIDs corresponding to the accounts. [to step 9]
   3. If no local accounts are available for the user at the SP, [to step 5]
9. IdP checks if the SP uses the account identifier mapping service. (SPs may specify this option on registration in IdP. For details on the service, refer to the IdP Interfaces>Back Channel Interfaces>Local Account ID Mapping Interface section of the Specification).
   1. If the SP uses the service, IdP sends UIDs retrieved at step 8b to the SP account identifier mapping service and retrieves login names corresponding to the UIDs. [to step 10]
   2. If the SP does not use the service, [to step 10].
10. IdP sends parameters to the SP to render the selecting local account IdP user interface. The SP receives the parameters and displays the UI to the user.
11. The user selects a local account.
12. IdP responds to the SP with <Response> SAML message containing specific information about the user. The SP retrieves the assertion and creates a local session for the user. [to step 2a]

Diagram

This diagram represents the described above model:

For details on the graphical conventions used in this diagram, refer to the Graphical Conventions section.

Remarks

• Each local session within an SP can be identified by a local account ID and session index (unique combination of letters and digits). If a user with a particular account ID has only one session opened in the SP, the session index is unnecessary.
• Each security assertion sent to an SP from IdP corresponds to a local session. If a local session is closed (user logged out), then respective assertion is discarded. It is recommended to set local session index equal to the identifier of a respective security assertion.
• An SP requires implementation of the Authentication Request protocol to perform operations defined at steps 3, 4, 12. For implementation details, see the Authentication Request Protocol section.
• An SP requires the IdP Front Channel interface to perform operations defined at steps 5, 6, 10. For implementation details, see the Front Channel Interface section.
• An SP requires the proxied authentication request service, and the service must provide the proxied authentication request interface to perform operations defined at step 7. For implementation details, see the Proxied Authentication Request Interface section.
• An SP requires local account ID mapping service, and the service must provide the account identifier mapping interface to perform operations defined at step 9. For implementation details, see the Local Account ID Mapping Interface section.