[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: SAML 2.0 Web Browser SSO Profile with Identity Provider Discovery
Here is a possible implementation of the SAML 2.0 Web Browser SSO Profile combined with the Identity Provider Discovery Profile. I could be way off on this so any comments would be greatly appreciated. 1) The client accesses a target resource at the SP. 2) A resource manager at the SP performs a security check on behalf of the target resource. Since a security context at the SP does not exist, the resource manager redirects the client to the inter-site transfer service at the SP. A TARGET parameter is appended to the redirect URL. 3) The client accesses the inter-site transfer service at the SP. 4) The inter-site transfer service redirects the client to a server in the common domain. The URI of the inter-site transfer service (with TARGET parameter) is appended to the redirect URL. 5) The client accesses the common domain server. 6) The common domain server checks for the common domain cookie. If the cookie does not exist, the common domain server returns a list of IdPs to the client. 7) The client chooses an IdP from the list and submits the form. 8) The common domain server creates the common domain cookie on the client and redirects the client to the inter-site transfer service at the SP. The URI of the preferred IdP is appended to the redirect URL. 9) The client accesses the inter-site transfer service at the SP (again). 10) The inter-site transfer service at the SP redirects the client to the single sign-on (SSO) service at the IdP. The TARGET parameter and a SAMLart parameter are appended to the redirect URL. 11) The client requests the SSO service at the IdP. 12) If a security context at the IdP does not exist, the SSO service redirects the client to the authentication authority (AA). The URI of the SSO service (with TARGET and SAMLart parameters) is appended to the redirect URL. 13) The client requests the AA at the IdP. 14) The AA challenges the user for credentials. 15) The user supplies the required credentials to the AA. 16) The AA verifies the user's credentials, creates a security context at the IdP and redirects the client to the SSO service. 17) The client requests the SSO service again. The TARGET parameter and SAMLart parameter have been preserved. 18) Since a security context now exists, the SSO service redirects the client to the inter-site transfer service. The TARGET parameter and SAMLart parameter are appended to the redirect URL. 19) The client requests the inter-site transfer service at the IdP. 20) The inter-site transfer service dereferences the artifact by sending a SAML ArtifactResolve message to the artifact resolution service at the SP. 21) The artifact resolution service at the SP returns a SAML ArtifactResponse message (containing an AuthnRequest element) to the inter-site transfer service at the IdP. 22) The inter-site transfer service at the IdP redirects the client to the assertion consumer service at the SP. The TARGET parameter and a new SAMLart parameter are appended to the redirect URL. 23) The client requests the assertion consumer service at the SP. 24) The assertion consumer service dereferences the artifact by sending a SAML ArtifactResolve message to the artifact resolution service at the IdP. 25) The artifact resolution service at the IdP returns a SAML ArtifactResponse message (containing an AuthnStatement element) to the assertion consumer service at the SP. 26) The assertion consumer service creates a security context at the SP and redirects the client to the target resource. 27) The client accesses the target resource at the SP (again). 28) Since a security context now exists, the resource is returned to the client. Notes: - If the inter-site transfer service at the SP knows the IdP at step 3 (because there is only one IdP or the URI of the IdP is included as a parameter in the request), skip steps 4--9. - If the common domain cookie already exists at step 5, skip steps 6 and 7. - If the user already has a security context at step 11, skip steps 12--17. - If the inter-site transfer service at the SP uses an HTTP Redirect or HTTP POST binding (instead of an HTTP Artifact binding) at step 10, skip steps 20 and 21. - If the inter-site transfer service at the IdP uses an HTTP POST binding (instead of an HTTP Artifact binding) at step 22, skip steps 24 and 25. Thanks, Tom Scavo http://trscavo.blogspot.com/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]