Shibboleth Developers

[Tom Scavo <>]

On Thu, 18 Nov 2004 11:52:32 -0500, Scott Cantor 
<>
 wrote:
> 
> > So you don't want to send the resource location in a parameter (a
> > problem you've noted before).  Yes, okay, then perhaps in that case a
> > standard return location is needed.  Doesn't that solve the problem?
> 
> Yes, it answers both your question about how to spoof it, and it addresses
> privacy, but it's also more metadata and configuration to document...

FYI, here's what the step-by-step flow of the IdP discovery profile
outlined in section 3.4 of the Architecture spec looks like (or at
least one possibility):

1) The client requests a target resource at the SP:

https://sp.org/myresource

The SP performs a security check on behalf of the target resource.  If
a valid security context at the SP already exists, skip steps 2–15.

2) The SP redirects the client to the cookie reading service at the WAYF.

3) The client requests the WAYF cookie reading service:

https://wayf.internet2.edu/InQueue/WAYF/read

The WAYF service processes the request by performing a cookie check.

4) The WAYF cookie reading service redirects the client to the cookie
processing service at the SP.  A parameter called providerId is
appended to the redirect URL if and only if the cookie exists.

5) The client requests the cookie processing service at the SP with a
providerId parameter attached:

https://sp.org/shibboleth/idp-discovery?
  providerId=https://idp.org/shibboleth/SSO

6) The cookie processing service redirects the client to the SSO
service at the IdP.  Three parameters are appended to the redirect
URL.

7) The client requests the SSO service at the IdP:

https://idp.org/shibboleth/SSO?
  target=https://sp.org/myresource&;
    shire=https://sp.org/shibboleth/SSO/POST&;
      providerId=https://sp.org/shibboleth/

The SSO service processes the authn request and performs a security
check.  If the user does not have a valid security context, the IdP
identifies the principal (details omitted).

8) The SSO service redirects the client to the cookie writing service
at the WAYF.

9) The client requests the WAYF cookie writing service:

https://wayf.internet2.edu/InQueue/WAYF/write?
  providerId=https://idp.org/shibboleth/

The WAYF service processes the request by updating the cookie.

10) The WAYF cookie writing service redirects the client to the cookie
processing service at the IdP.

11) The client requests the cookie processing service at the IdP:

https://idp.org/shibboleth/idp-discovery

12) The SSO service responds with an HTML form as in step 4 of the
ordinary Browser/POST profile.

13) The client issues a POST request to the assertion consumer service
at the service provider as in step 5 of the ordinary Browser/POST
profile.

14) The assertion consumer service processes the authn response,
creates a security context at the SP and redirects the client to the
target resource.

15) The client requests the target resource at the SP (again):

https://sp.org/myresource

16) Since a security context exists, the SP returns the resource to the 
client.