Federated Authentication

The responsibility of the federated authenticators is to authenticate the user with an external system. This can be with Facebook, Google, Yahoo, LinkedIn, Twitter, Salesforce or any other identity provider. Federated authenticators are decoupled from the Inbound Authenticators. Once the initial request is handed over to the authentication framework from an inbound authenticator, the authentication framework talks to the service provider configuration component to find the set of federated authenticators registered with the service provider corresponding to the current authentication request.

A federated authenticator has no value unless it is associated with an identity provider. For example, the Identity Server supports SAML 2.0, OpenID, OpenID Connect, OAuth 2.0 and WS-Federation (passive). The SAML 2 .0 federated authenticator itself has no value, it has to be associated with an identity provider. Google Apps can be an identity provider with the SAML 2.0 federated authenticator. This federated authenticator knows how to generate a SAML request to the Google Apps and process a SAML response from it.

There are two parts in a federated authenticator.

Request Builder
Response Processor

Once the federation authentication is successfully completed, the federated authenticator notifies the authentication framework. The framework can now decide that no more authentication is required and hand over the control to the corresponding response builder of the inbound authenticator. Both the request builder and the response processor are protocol aware, while the authentication framework is not coupled to any protocol. See Architecture for more information on this overall process.

To configure federated authentication with different protocols see the following topics.