myVocs !IdP Discovery

The current myVocs architecture (see topic Introduction to myVocs) relies on a Federation-level "Where are you from?" (WAYF) service for !IdP discovery. This topic describes an enhanced !IdP discovery process for myVocs based on the SAML 2.0 !IdP Discovery Profile, which allows SPs to more easily discover the browser user's preferred !IdP. (The reader is referred to section 4.3 of the SAML 2.0 Profiles specification for background material.)

Essentially, the proposed architecture moves the !IdP discovery process into the heart of myVocs:

The potential advantages of this architecture include:

• improved user experience
• flexible, plug-and-play Discovery Service
• complete knowledge of user history

SAML 2.0 !IdP Discovery Profile

In what follows, we rely heavily on the following concepts from the SAML 2.0 spec:

• Common Domain
• Common Domain Cookie
• Common Domain Cookie Writing Service
• Common Domain Cookie Reading Service

The Common Domain is home to the Common Domain Cookie and the Reading/Writing Services. The Common Domain Cookie (CDC) is essentially an !IdP history list. The CDC Reading and Writing Services perform Cookie getter and setter functions, respectively. Together these components comprise the SAML 2.0 !IdP Discovery Profile.

The myVocs Implementation

In myVocs, the Reading and Writing Services are implemented as servlet filters. The Writing Service filters requests to the myVocs !IdP (!IdP

0

), which is protected by the myVocs SP (SP

0

). The Writing Service is therefore a protected resource. The Reading Service, on the other hand, is unprotected. It filters requests to the myVocs Discovery Service, which is a WAYF-like entity. Unlike the Federation WAYF, which redirects a Shibboleth Shibboleth.AuthnRequest to an !IdP (such as !IdP

1

), the Discovery Service redirects the client to a Shibboleth.SessionInitiator at the myVocs SP (SP

0

).

The initial goal of this implementation is quite modest, namely, to display a simplified confirmation! page to the end user. Instead of a complete list of federation !IdPs, however, the user is presented with a short list of recently visited !IdPs, in reverse chronological order. For the majority of users, this list will be of length one, hence, we use the term confirmation page in what follows.

Assuming most users have an account at most one !IdP, an obvious simplification is to automatically redirect to the only !IdP on the list (without confirmation). However, what if the user wishes to use a different !IdP at a later time? Since all interaction with the user has been circumvented, there is no opportunity to choose an alternate !IdP. For this and other reasons, we choose to always display a confirmation page, at least for this initial implementation.

The protocol flow described previously (see topic Introduction to myVocs) omitted the WAYF for simplicity. Here we describe the complete flow, including the proposed !IdP discovery process:

1. A browser client requests a VO web resource protected by SP
   1
   . If a security context for the principal already exists at SP
   1
   , skip to step 22.
2. The client is redirected to the Reading Service, which is an unprotected myVocs resource.
3. The client makes a Shibboleth Shibboleth.AuthnRequest (targeted at SP
   1
   ) to the Reading Service. The CDC is included in the header of this request.
4. The Reading Service parses the CDC and returns a simple confirmation! page to the client.
5. The client clicks the "Login" button and submits the form to the Reading Service.
6. The Reading Service redirects the client to the Writing Service, which is a Shibboleth.SessionInitiator for SP
   0
   . The redirect URL has two parameters. The target parameter is the request URL at step 3. The providerId parameter is the user's preferred !IdP from the confirmation page.
7. The client makes a Shibboleth.SessionInitiator protocol request to the myVocs !IdP (!IdP
   0
   ). If a security context for the principal already exists at the !IdP
   0
   , skip to step 16.
8. The client is redirected to the federation !IdP (!IdP
   1
   ).
9. The client makes a second Shibboleth Shibboleth.AuthnRequest (targeted at SP
   0
   ) to the SSO service at !IdP
   1
   . If a security context for the principal does not exist, !IdP
   1
   identifies the principal (details omitted).
10. !IdP
    1
    updates the security context for this principal, issues an authentication assertion, and returns an authentication response to the client.
11. The client submits the authentication response to the assertion consumer service at SP
    0
    . The assertion consumer service validates the authentication assertion in the response and passes control to the attribute requester.
12. The attribute requester queries the attribute authority at !IdP
    1
    .
13. The attribute authority returns an attribute response to the attribute requester.
14. SP
    0
    updates its security context for this principal and redirects the client to the Writing Service.
15. The client makes a Shibboleth Shibboleth.AuthnRequest to the Writing Service, the same Shibboleth.AuthnRequest made at step 3. The Writing Service updates the CDC in the response and lets the request pass through to !IdP
    0
    .
16. !IdP
    0
    filters the attributes from the header of the request (by virtue of the attribute exchange in steps 12 and 13), persists these attributes to the VO database (if necessary), and returns an authentication response to the client.
17. The client submits the authentication response to the assertion consumer service at SP
    1
    . The assertion consumer service validates the authentication assertion in the response and passes control to the attribute requester.
18. The attribute requester queries the attribute authority at !IdP
    0
    .
19. The attribute authority returns an attribute response to the attribute requester. Both federation attributes (persisted at step 16) and VO attributes are included in the response.
20. SP
    1
    updates its security context for this principal and redirects the client to the VO resource.
21. The client requests the VO resource, the same request issued at step 1.
22. The resource filters the attributes from the header of the request (by virtue of the attribute exchange in steps 18 and 19), makes an access control decision, and returns the resource to the client.

If the CDC is missing or ill-formed at step 3 above, the Reading Service lets the request pass through to the Discovery Service, which returns a menu of possible IdPs to the client at step 4. The user chooses an !IdP from the menu and submits the form at step 5. Again the Reading Service lets the request pass through to the Discovery Service, which subsequently redirects the client to the Writing Service. The redirect URL is precisely the same form as the redirect URL in step 6 above.