There are two main roles in a browser SSO transaction, the Identity Provider (IDP) who is responsible for authenticating the identity and generating a security token and the Service Provider (SP) who consumes that security token (receives and validates it) and translates the asserted identity into an application session.
Along with the Identity Provider and Service Provider roles, there are a number of components that complete the overall federation scenario:
|Security Token||The security token or assertion is used to convey the identity of the authenticated user from the IDP over to the SP in a standard manner. The assertion contains security attributes, a digital signature and identity attributes. A SAML assertion and an OpenID Connect ID token are examples of federated security tokens.|
|Identity Store||The Identity Store is where the user authentication data is stored. Federation allows for this ID store to be moved from the Service Provider to the Identity Provider reducing the password proliferation challenge. A single identity store can be used to store passwords leading to increased security.|
|Authentication Integration Point||The interface that the authentication provider uses to authenticate the user. This may be a HTML form, an X509 certificate, Windows Authentication or other custom authentication process such as multi-factor.|
|Application Integration Point||On the Service Provider side, once a security token has been issued, received and validated at the SP an application session can be generated based on the asserted identity. The process to integrate an application into the federated process occurs at this application integration point.|
|Federated Trust||For a Service Provider to trust an assertion generated by an Identity Provider a federated trust must be established. Generally this is achieved by swapping a metadata file which contains information about the connection and a digital signature certificate.|