Shibboleth Developers

["Scott Cantor" <>]

Not surprisingly, I have some concerns.

>  + The user's preferred IdP should be on a per-SP basis.

I'm not at all convinced this is tremendously useful, but I concede it might
be slightly useful for some deployments. I wonder if you're basing way too
much on the assumption that it's useful, though. Why do you think this? Some
real world experience?

>  + Each user has an associated IdP history list (which is what the
> common domain cookie really is), which may be used to initialize form
> controls and silently redirect the client (if desired).

Note "silent redirect" means "user can't change his mind", which is the crux
of the problem. Users won't know to travel to a "cookie manager" page unless
something else they already know well directs them to it (i.e. their IdP
does it).

> - Give each SP its own (virtual) directory on the WAYF server:
> 
>  https://wayf.internet2.edu/InQueue/WAYF/sp1.edu
>  https://wayf.internet2.edu/InQueue/WAYF/sp2.edu
>  etc.

I think I'd vastly prefer a strategy that lets us use simple query strings
here. We already have a protocol for an SP to send a request to the WAYF and
include it's providerId parameter, I'd rather use that. This breaks some of
your cookie handling trickery (and I'm not sure it even works, see below),
but that's no reason to invent a whole new, incompatible approach.

> This is the same InQueue location URL used today except for the "extra
> path" information "/sp1.edu", "/sp2.edu", etc.

Right, but we don't need new stuff here, what we have already works. You can
do it by just dropping cookies with names based on the SPs, etc. Again, I
think the per-SP notion is an extreme exception, not at all the rule. Use a
common cookie, and override when told to. My guess is few will, but I'm
guessing (and I think you are too).

The shared history/default cookie can essentially be whatever you want as I
already said, but I think it behooves us to encourage people to use the
format and name laid out already in the SAML spec because it works.

> The WAYF responds by appending a providerId parameter to the return
> URL.  The value of the providerId parameter is the complete value of
> the _shib_idp_history cookie.  The SP may use this list of providerIds
> to interact with the user or it may redirect the client to one of the
> IdPs in the list.

Disagree. It's potentially too long. That's why I specifically said we
should return the last one in the list. I don't think we can afford to
return the whole thing. I guess we could DEFLATE it, etc., but that seemed
like overkill to me. If you need that kind of functionality, we can offer
shared domain space with the WAYF so SPs can use the regular SAML profile.

> - Cookie _shib_idp_history is similar to _saml_idp except
> 
>  + The name has the suffix "history", which accurately reflects the
> value of the cookie.
>  + The IdP providerIds are not base64 encoded.
>  + The path is explicitly set to the base path of the WAYF.
>  + The domain is not set.
> 
> (Note: All of the above are bugs in the SAML2 IdP Discovery profile.)

I disagree. The name, who cares? The base64 thing is unneeded and may or may
not go away, but it's hardly a bug. The domain and path should align to the
SAML profile so that this cookie can double for that purpose. Essentially I
see no justification for inventing a new cookie that copies the old one but
does less?

But, all that said, it doesn't matter. If the cookie's not shared, do what
you want with it. It doesn't belong in the spec.

The main issue is that you want to let the SP get the whole value sent to it
on a URL, but I don't think that's practical as a spec without compression.

> Cookie _shib_idp_history is sent to the WAYF server along with this
> request.  Subsequently, the user is presented with form controls that
> allow the history list to be modified.  Upon submission, the WAYF
> overwrites the value of cookie _shib_idp_history.  All this does is
> change the initial value of subsequently presented form controls.

Right, but all this is private to the WAYF. I don't need to spec it.

> - More importantly, when the user requests
> 
>  https://wayf.internet2.edu/InQueue/WAYF
> 
> all cookies named _shib_idp are likewise sent along with the request
> (since each of the virtual directories is in the appropriate subtree).

Umm...don't think so. Maybe I'm wrong, but I thought if you left the path
off for those cookies, you ended up constraining them to that subtree only,
in which case they won't be sent to the root path alone. Otherwise, you're
implying they are global to the tree, but then the names would collide...

Am I confused?

To sum up, my opinion is that all of this is fine except that you should be
able to do most/all of what you want to implement using the two existing
SP->WAYF URLs I defined, one which is a core part of Shib since the
beginning, and the other small bit in my new proposal about discovery.

The point is, the implementation should not try to impose a set of
interactions peculiar to it on the Shib protocol. It's not necessary.

-- Scott