Nested single sign-on flows (Federation)

We can nest SAML or OpenID Connect single sign-on flows. That is, we can resume an initial SSO flow after the completion of a second SSO flow.

For SAML, a nested SSO flow means the involvement of an IdP proxy between a real service provider (SP) and a real identity provider (IdP). The IdP proxy delegates the user credentials authentication to the real IdP.

For OpenID Connect, a nested SSO flow means the involvement of an OAuth provider (OP) proxy between a real relying party (RP) and a real OP. The OP proxy delegates the user credentials authentication to the real OP.

A nested SSO flow involves the following two SP or RP-initiated SSO flows:

After the second SSO flow completes the authentication of credentials with the real IdP or OP, the IdP or OP proxy has an implicit mechanism to resume the first SSO flow to sign in to the real SP or RP.

When we install an appliance to work as an IdP proxy, create an identity provider and service provider federation and map them to a single reverse proxy instance. See Configure a reverse proxy point of contact server. Configure the proper mapping rules in the IdP proxy federations to avoid duplicate attributes in STSUU to attain the successful flow of nested SSO. See the following topics: .

--> -->
First SSO flow Second SSO flow
SAML (HTTPRedirect, HTTPPost, HTTPArtifact) SAML (HTTPRedirect, HTTPPost, HTTPArtifact)
SAML (HTTPRedirect, HTTPPost, HTTPArtifact) OpenID Connect
OpenID Connect OpenID Connect
OpenID Connect SAML (HTTPRedirect, HTTPPost, HTTPArtifact)

The following supported nested flows are for the authentication delegated to the external IdP during an OAuth20 flow:

--> -->
First flow Second flow
OAuth20 SAML (HTTPRedirect, HTTPPost, HTTPArtifact)
OAuth20 OpenID Connect


Parent topic: Federation configuration