SAML IdP Proxy

A SAML IdP Proxy is a bridge or gateway between a federation of SAML IdPs and a federation of SAML SPs:

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.

The following flow diagram illustrates the relationship among the various IdP Proxy components:

Here is an outline of the typical IdP Proxy flow:

1. A browser client requests a web resource protected by a SAML SP (SP₀). If a security context for the principal already exists at SP₀, skip to step 14.
2. The client is redirected to the IdP component of the IdP Proxy (IdP₀), which is protected by the SP component of the IdP Proxy (SP₁).
3. The client makes a SAML AuthnRequest to the SSO service at IdP₀. If a security context for the principal already exists at IdP₀, skip to step 10.
4. The AuthnRequest is cached and the client is redirected to the terminal IdP (IdP₁).
5. The client makes a SAML AuthnRequest to the SSO service at IdP₁. If a security context for the principal does not exist, IdP₁ identifies the principal (details omitted).
6. IdP₁ updates its security context for this principal, issues one or more assertions, and returns a response to the client.
7. The client submits the response to the assertion consumer service at SP₁. The assertion consumer service validates the assertions in the response.
8. SP₁ updates its security context for this principal and redirects the client to IdP₀.
9. The client makes a SAML AuthnRequest to IdP₀, the same AuthnRequest made at step 3.
10. IdP₀ updates its security context for this principal, issues a single assertion, and returns a response to the client. The response may also contain the assertions issued by IdP₁ at step 6.
11. The client submits the response to the assertion consumer service at SP₀. The assertion consumer service validates the assertions in the response.
12. SP₀ updates its security context for this principal and redirects the client to the resource.
13. The client requests the resource, the same request issued at step 1.
14. 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₁ issues an authentication response containing one or more assertions at step 6, which is subsequently consumed by SP₁ at step 7, and likewise IdP₀ issues an authentication response containing a single assertion at step 10, which is consumed by SP₀ at step 11. These authentication responses will contain assertions that themselves contain authentication statements and (optionally) attribute statements. Although IdP₀ is not authoritative for the authentication context and attributes asserted by IdP₁, SP₀ 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₁ exposes the assertions it receives from IdP₁, the IdP Proxy formulates the following assertion at step 10:

<!-- SAML1 assertion issued by IdP0 to SP0 -->
<saml:Assertion ...>
  <saml:Conditions ...>...</saml:Conditions>
  <saml:Advice>
	 <!-- nested assertion issued by IdP1 to SP1 -->
	 <saml:Assertion ...>
		<saml:Conditions ...>...</saml:Conditions>
		<saml:AuthenticationStatement ...>
		  <!-- the subject that authenticated to IdP1 -->
		  <saml:Subject>...</saml:Subject>
		  ...
		</saml:AuthenticationStatement>
		<saml:AttributeStatement>
		  <saml:Subject>...</saml:Subject>
		  ...
		</saml:AttributeStatement>
	 </saml:Assertion>
  </saml:Advice>
  <saml:AuthenticationStatement ...>
	 <!-- the subject that (indirectly) authenticated to IdP0 -->
	 <saml:Subject>...</saml:Subject>
	 ...
  </saml:AuthenticationStatement>
  <saml:AttributeStatement>
	 <saml:Subject>...</saml:Subject>
	 ...
  </saml:AttributeStatement>
</saml:Assertion>

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₀. In particular, an assertion issued by IdP_j to SP_j has N - j levels of nesting. SP_j accesses the nested assertion issued by IdP_k (k > j) by recursing on the assertion issued by IdP_j precisely k - j times.