Tuesday, 27 November 2007
Dynamic Federation - Under the Covers
This morning Andre posted some high level details on our company blog (here) around how to automate federation connectivity via what we are calling dynamic federation. I thought it would be helpful to dig a little deeper and describe how we see this working under the covers.
It is important to note that nothing defined below is proprietary and that everything is already specified in the SAML 2.0 speciification. For this to succeed we are proposing that two conventions be adopted. The first is for the optional use of email address to bootstrap IdP Discovery for SP-Initiated SSO. The second is to standardize on an EntityID URL format that can be derived from a domain name (i.e. abc.com maps to a SAML entirity id of https://saml.abc.com).
Here is a sample message flow.
1. User attempts to access a resource at the SP and is prompted for their email address as an identifier (this is likely their corporate email address).
2. User is redirected to the SP federation server with domain name as a query parameter.
3. SP federation server checks domain name against white list to determine if this is a trusted SSO-enabled IdP.
4. SP federation server retrieves and caches signed meta-data file from IdP at the URL expressed by the IdP’s entityid - http://saml.idp-domain-name.com. The metadata contains the IdP's certificate, the SSO Service endpoint and optionally single logout endpoints. The federation server verifies the meta-data signature and ensures that the attached certificate is valid. The federation server validates that the domain name of the IdP matches the signing certificate DN.
5. SP federation server redirects user to IdP SSO URL with signed AuthNRequest.
6. IdP federation server checks white list using domain name from Issuer field in AuthNRequest.
7. IdP federation server validates the AuthNRequest. The federation server retrieves and caches signed metadata file from SP at the URL expressed by the SP’s entityid - http://saml.sp-domain-name.com. The metadata contains the SP's certificate, the Assertion Consumer Service endpoint and optionally single logout endpoints and attribute requirements. The federation server verifies the meta-data signature and ensures that the attached certificate is valid. The federation server validates that the domain name of the SP matches the signing certificate DN.
8. IdP authenticates user.
9. IdP federation server creates SAML Assertion containing users email address (and other optional attributes) and uses the SAML Post Binding to redirect the user back to the SP.
10. SP federation server validates the SAML Assertion (including verifying the signature over SAML Response) and checks its white list using the domain name from the Issuer field in the SAML Response.
11. The SP generates the local session cookie and redirects the browser to the requested resource.
1. User attempts to access a resource at the SP and is prompted for their email address as an identifier (this is likely their corporate email address).
2. User is redirected to the SP federation server with domain name as a query parameter.
3. SP federation server checks domain name against white list to determine if this is a trusted SSO-enabled IdP.
4. SP federation server retrieves and caches signed meta-data file from IdP at the URL expressed by the IdP’s entityid - http://saml.idp-domain-name.com. The metadata contains the IdP's certificate, the SSO Service endpoint and optionally single logout endpoints. The federation server verifies the meta-data signature and ensures that the attached certificate is valid. The federation server validates that the domain name of the IdP matches the signing certificate DN.
5. SP federation server redirects user to IdP SSO URL with signed AuthNRequest.
6. IdP federation server checks white list using domain name from Issuer field in AuthNRequest.
7. IdP federation server validates the AuthNRequest. The federation server retrieves and caches signed metadata file from SP at the URL expressed by the SP’s entityid - http://saml.sp-domain-name.com. The metadata contains the SP's certificate, the Assertion Consumer Service endpoint and optionally single logout endpoints and attribute requirements. The federation server verifies the meta-data signature and ensures that the attached certificate is valid. The federation server validates that the domain name of the SP matches the signing certificate DN.
8. IdP authenticates user.
9. IdP federation server creates SAML Assertion containing users email address (and other optional attributes) and uses the SAML Post Binding to redirect the user back to the SP.
10. SP federation server validates the SAML Assertion (including verifying the signature over SAML Response) and checks its white list using the domain name from the Issuer field in the SAML Response.
11. The SP generates the local session cookie and redirects the browser to the requested resource.
