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 .
The functions of an SP are as follows:
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.
As the SP stores all local accounts data, it decides if a local account is authorized to access a specific SP resource.
After a user is authorized, the SP opens a local session for such user to prevent re-authorization on each request.
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.
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.
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.
The first three functions are standard for a typical SP; to perform the latter four functions, an SP requires specific programming interfaces.
The functions of IdP are as follows:
IdP has a programming interface via which an SP can configure its presence in an SSO system.
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).
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:
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.