Nested single sign-on flows

You can nest SAML or OpenID Connect single sign-on flows. That is, you 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:

  • Between the real SP or RP and an IdP or OP proxy.
  • Between the IdP or OP proxy (acts as an SP or RP) and the real IdP or OP.

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 you 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 Configuring a reverse proxy point of contact server.

Note: 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: .
Table 1. Supported nested SSO combinations
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:

Table 2. Supported nested OAuth flow combinations
First flow Second flow
OAuth20 SAML (HTTPRedirect, HTTPPost, HTTPArtifact)
OAuth20 OpenID Connect