OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[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]