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.
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 |