SAML
...
IdP Proxy
A SAML ! IdP Proxy is a bridge or gateway between a federation of SAML IdPs and a federation of SAML SPs:
Image Removed
Image Added
To an SP, an ! IdP Proxy looks like an ordinary ! IdP. Likewise, to an ! IdP, an ! IdP Proxy looks like an SP. Thus an ! IdP Proxy has the combined capability of both an ! IdP and SP.
Like a Web (HTTP) Proxy, an ! IdP Proxy delivers increased efficiency, security, and flexibility.
| Web Proxy | IdP Proxy |
Efficiency | cache web pages | cache attributes |
Security | controlled access to web pages | controlled access to federation IdPs |
Flexibility | HTTP request/response filtering | SAML request/response filtering |
The following flow diagram illustrates the relationship among the various ! IdP Proxy components:
Image Removed
Image Added
Here is an outline of a the typical ! IdP Proxy flow:
- A browser client requests a web resource protected by a SAML SP (SP0). If a security context for the principal already exists at SP0, skip to step 14.
- The client is redirected to the ! IdP component of the ! IdP Proxy (!IdP0), which is protected by the SP component of the ! IdP Proxy (SP1).
- The client makes a SAML Shibboleth.AuthnRequest to the SSO service at ! IdP0. If a security context for the principal already exists at ! IdP0, skip to step 10.
- The client is redirected to the terminal ! IdP (!IdP1).
- The client makes a SAML Shibboleth.AuthnRequest to the SSO service at ! IdP1. If a security context for the principal does not exist, ! IdP1 identifies the principal (details omitted).
- !IdP1 updates its security context for this principal, issues one or more assertions, and returns a response to the client.
- The client submits the response to the assertion consumer service at SP1. The assertion consumer service validates the assertions in the response.
- SP1 updates its security context for this principal and redirects the client to ! IdP0.
- The client makes a SAML Shibboleth.AuthnRequest to ! IdP0, the same Shibboleth.AuthnRequest made at step 3.
- !IdP0 updates its security context for this principal, issues a single assertion, and returns a response to the client. The response also contains the assertions issued by ! IdP1 at step 6.
- The client submits the response to the assertion consumer service at SP0. The assertion consumer service validates the assertions in the response.
- SP0 updates its security context for this principal and redirects the client to the resource.
- The client requests the resource, the same request issued at step 1.
- The resource makes an access control decision based on the security context for this principal and returns the resource to the client.
There are at least two assertions produced as a result of the previous transaction. Observe that ! IdP
1 issues an authentication response containing one or more assertions at step 6, which is subsequently consumed by SP
1 at step 7, and likewise
! IdP
0 issues an authentication response containing a single assertion at step 10, which is consumed by SP
0 at step 11. These authentication responses will contain assertions that themselves contain authentication statements and (optionally) attribute statements. Although
! IdP
0 is not authoritative for the authentication context and attributes asserted by
! IdP
1, SP
0 may wish to take all assertions into account to make a fully informed access control decision. We therefore propose a precise packaging of multiple assertion elements below.
Assuming SP
1 exposes the assertions it receives from
! IdP
1, the
! IdP Proxy formulates the following assertion at step 10:
...
More generally, suppose there are N ! IdP Proxies in a chain. Every ! IdP Proxy in the chain gives rise to an additional level of nesting in the assertion issued to SP
0. In particular, an assertion issued by
! IdP
j to SP
j has
N - j levels of nesting. SPj accesses the nested assertion issued by ! IdPk (k > j) by recursing on the assertion issued by ! IdPj precisely k - j times.
| HTML |
|---|
<hr />