Inter-Federation Scenario Details

From Project Concordia

Jump to: navigation, search

Contents

Scenario - Chained SAML 2/WS-Federation SSO

This scenario is characterized by chained passive browser SSO flows, either with the SAML 2 protocol preceeding WS-Federation, or vice-versa. This is accomplished by having some endpoints act as protocol bridges, either acting as both a SAML IdP and a WS-Fed RP or as a WS-Fed IP and a SAML SP.

This scenario is the first public demonstration of inter-federation using SAML 2.0 tokens between a federation using the SAML 2.0 protocol and a federation using WS-Federation.

The tokens passed between the different federations are the same SAML 2.0 tokens that are used in the Infocard Authentication Scenario. Ideally, the content of these tokens is passed unaltered across the protocol bridges. However, a bridge will likely need to re-write and re-issue/sign tokens to account for differences between protocols in terms of SSO profile requirements and processing rules. We will assume that all providers adhere to the normative requirements of the SSO protocol profiles they implement. (The authentication requests and responses are also the same as for the Infocard scenario, so these are not repeated here.)

If possible, the protocol bridges should also translate any authentication request received from one protocol to the other. For instance, a samlp:AuthnRequest originating within a SAML federation should be translated such that the authentication mechanism identified in a samlp:RequestedAuthnContext is represented in a WS-Federation WAuth request parameter, or vice-versa. For simplicity in reusing providers from the Infocard scenario, we will assume support in this scenario for the same Infocard authentication mechanism URIs.

Inter-Federation from WS-Federation to SAML 2

Image:Inter-Federation Fed to SAML.png

Flow

  1. User presents self to a WS-Federation Relying Party.
  2. WS-Fed redirects the user to a bridge site acting as a WS-Fed Identity Provider.
  3. Bridge site acts as a SAML Service Provider, redirecting the user to the SAML Identity Provider .
  4. SAML IdP authenticates the user such that the original authentication request is satisfied.
  5. SAML IdP sends a SAML 2 token with the authentication context to the bridge site acting as a SAML SP.
  6. Bridge site acts as a WS-Fed IP, passing the token received on to the WS-Fed RP.
  7. User is logged into the WS-Fed RP with appropriate privileges. For demonstration purposes, the WS-Fed RP should display the claims from the SAML 2.0 token and the authentication context information received.

Inter-Federation from SAML 2 to WS-Federation

Image:Inter-Federation SAML to Fed.png

Flow

Image:Scenario2-flow.png

  1. User presents self to a SAML 2.0 Service Provider.
  2. SAML redirects the user to a bridge site acting as a SAML Identity Provider.
  3. Bridge site acts as a WS-Federation Relying Party, redirecting the user to the WS-Fed Identity Provider.
  4. WS-Fed IP authenticates the user such that the original authentication request is satisfied.
  5. WS-Fed IP sends a SAML 2 token with the authentication context to the bridge site acting as a WS-Fed RP.
  6. Bridge site acts as a SAML IdP, passing the token received on to the SAML SP.
  7. User is logged into the SAML SP with appropriate privileges. For demonstration purposes, the SAML SP should display the claims from the SAML 2.0 token and the authentication context information received.
Retrieved from "http://projectconcordia.org/index.php/Inter-Federation_Scenario_Details"