Re: [security-services] How does Shib WAYF work? (was: Re:[security-services] IdP Discovery)

["RL 'Bob' Morgan" <rlmorgan@washington.edu>]

> 0. A WAYF is a distinct service and implementation thereof that is run 
> on some network node. (yes?)

Like most services, it can be run either on a separate machine from the SP 
or on the SP itself.  In usual practice it is shared among many SPs, which 
lets the user leverage one instance of discovery across all those SPs (via 
a cookie from the WAYF) if desired.

> 1. So each SP that is Shib-enabled is configured with one or more WAYFs 
> to use?

Here's a key point, often missed:  the WAYF is intended as a discovery 
scheme of last resort, for those few apps that can live with its serious 
limitations.  Much better is for the app to handle IdP discovery in some 
fashion appropriate to it.  For example see http://sciencedirect.com/ 
(click on the Athens/institutional login link).  Not that this is the 
ultimate discovery UI, but it shows how the app can do better than a plain 
WAYF; in this case the app has to deal with many federations, ie more IdPs 
than any single operational WAYF currently represents.

What Shib supports directly in the SP is a URL to forward clients to when 
authentication is needed.  The SP doesn't know whether that URL is an IdP 
or an IdP discovery service; it's the same request either way.

> 3. My understanding of Shib's conventions are that individual users are 
> not supposed to have to manually type in anything wrt identifying their 
> IDP.

Since it's preferred that IdP discovery be done in the app, apps are free 
to do this however they want.

The vanilla WAYF (visible via https://www.internet2.edu/secure/env.php) 
does permit users to type stuff in to search in its IdP list.

> So, a given WAYF either has to be config'd with lists of IDPs it knows 
> about, or it gets info dynamically from the UA (via e.g. _saml_idp CDC), 
> or a combination, yes?

The WAYF typically gets its IdP list from the federation metadata.  Shib 
has not (I believe) implemented the shared-cookie IdP discovery method.

> What happens if the WAYF can't determine an IDP for a given UA/user to 
> use with a given SP?

The method is that the user selects one of the offered IdPs.  So if the 
user doesn't select one, they'll sit there staring at the WAYF page.  Note 
that the generic WAYF has no idea which IdPs are appropriate for which 
SPs.

> 4. The Shib WAYF isn't necessarily wedded to SAML profiles as the 
> subsequent SSO protocol vehicle, yes?

Dunno quite what you mean by this, but thus far it only supports 
SAML-based web signon.

> It's interesting to compare the Shib WAYF to Yadis -- both do IDP 
> discovery/introduction, and both supply IDP metadata to the SP.

The WAYF doesn't supply IdP metadata to the SP, it's just used for user 
routing.

> Without yet answers to the above questions, it seems that the salient 
> differences between YADIS (as far as I presently understand it) and Shib 
> WAYF are..
>
> D1. Yadis isn't a distinct service (WAYF is), rather it's a methodology for 
> an SP to dereference a user-supplied identifier and obtain a pointer to an 
> IDP and metadata thereof.

Right, so in that sense they're complementary.  Eg, an SP could go through 
the Yadis dance and decide at some point to send the user to a WAYF; or 
could send the user to a WAYF that itself could do Yadis.

  - RL "Bob" (=rlbob 8^)