Functions of SSO System Participants

This section touches upon functions performed by an SP and IdP in an SSO system. For details on how the functions are used, and how different functions are connected, see the sections How SSO Works, Management Operations, Single Logout Is and How It Is Achieved .

SP

The functions of an SP are as follows:

• Manage local accounts.

  Local accounts are used to access resources of a specific SP. An SP can create a local account for a user, update local account settings or remove the account. All information about local accounts is stored in an SP database.

• Authorize users of its local accounts.

  As the SP stores all local accounts data, it decides if a local account is authorized to access a specific SP resource.

• Manage local sessions.

  After a user is authorized, the SP opens a local session for such user to prevent re-authorization on each request.

• Configure presence in an SSO system.

  To be a part of an SSO system, an SP registers in IdP. In case SP or IdP settings are changed, an SP updates its registration in IdP. To leave the SSO system, an SP cancels its registration in IdP.

• Enforce users authentication to IdP.

  In an SSO system, users authentication is performed at IdP side. SP uses specific IdP interfaces to provide IdP with data required for users authentication.

• Provide opportunity for managing global accounts and FIs.

  Global accounts and FIs are designed to provide access to multiple local accounts without entering local accounts credentials.

  Federated identity is an entity which contains a set of local account IDs. These IDs pertain to local accounts of a single SP or different SPs. Each FI corresponds to a single global account and vice versa. The only purpose of a global account is to store credentials corresponding to a specific FI. If a user specifies global account credentials when authenticating to IdP, the FI corresponding to the global account is used to identify what local accounts are accessible to the user.

   

• Provide opportunity for performing single logout.

The first three functions are standard for a typical SP; to perform the latter four functions, an SP requires specific programming interfaces.

IdP

The functions of IdP are as follows:

• Link together SPs in an SSO system.

  IdP has a programming interface via which an SP can configure its presence in an SSO system.

• Store global accounts and federated identities.

• Manage global sessions.

  Global session links together all local sessions opened for a specific user. IdP opens a global session for a user agent (while local sessions are opened for a specific tab/window of a user agent).

   

• Manage single logout.
  
• Authenticate users.

  First, a user attempts to reach an SP resource. If the user is not authorized to access a specific resource, he is forwarded to IdP for authentication. All authentication-related data is exchanged directly between IdP and user agent (browser). To communicate with users and hide that the communication is held by a party different from the SP, IdP uses IdP user interfaces. These interfaces are used to resolve the following two issues:

  1. A user should not know anything about IdP; the only thing that concerns the user is services provided by SPs.
  2. A user should not feel any difference in appearance of user interfaces provided by SPs and IdP. For instance, a user can be confused if the design of an HTML form for entering credentials differs from design of other content provided by an SP.

  An IdP user interface is always presented by an HTML form. The form design and layout are dictated by an SP. IdP only sends parameters that enable an SP to identify a specific form. After an SP retrieves form parameters, it renders the form design and layout.

  Once the form is rendered, the SP displays this form to a user agent. When a user submits the form, the data is sent to IdP. The Specification recommends to send the data directly by specifying a corresponding IdP endpoint URL in a form ACTION field when rendering an IdP user interface.

  To distinguish different IdP user interfaces, we gave them unique names. According to the Specification, there is one-to-one correspondence between HTML forms and operations via the Front-Channel interface, so it is proposed to inherit an IdP user interface name from the name of a corresponding operation. Example: challenging for credentials IdP user interface. According to accepted naming conventions and the Specification, there are five IdP user interfaces (challenging for credentials, selecting local account, associating local account ID with FI, detaching local account ID from FI, updating global account). The latter three IdP user interfaces are hereby called FI management IdP user interfaces.