Discovery and protocols

[Cantor, Scott]

On 12/29/11 10:34 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:

>I'm looking for input about how discovery should handle the issues of
>protocol.

A lot of this is really more to do with SP error handling than anything
else.

>- Does it suffice to just look for the correct endpoint or should one
>check for "urn:mace:shibboleth:1.0" in the
>protocolSupportEnumeration?  My instinct is that one has to do both.

You could, but if you declare a role of "IDP" with that protocol, you're
obligated to support at least one SSO service of that type. That's just
punting the problem to metadata publishers, but I prefer to do that where
possible. Software can't solve the problem of sloppy metadata.

It would be different if you were expecting something more optional to be
present.

>- If an IdP is dropped from the display list because it does not declare
>itself as supporting the correct protocols, what (if any)
>feedback should be provided (both to the admin and to the end user).  My
>instinct is that all we can do is log the dropping of the IdP (at DEBUG)
>and that's it.

The filtering assumption is that it's acceptable to hide choices from
users. If you want the experience of always presenting a consistent list,
then you wouldn't filter, and you have to handle the errors instead. I
don't pretend to know which is better, but the point here isn't to give
users two lists and try to explain why the second set don't work.

>Given that this is for a legacy protocol I'm really not too worried about
>it, but it does a question of whether the CDS should be doing anything
>about (SAML) protocols when it is speaking Discovery protocol.  A major
>motivation of Discovery protocol was to delegate protocol decisions to
>the SP, but my concern is that the SP can get stranded if a user is
>directed to a DS and selects an IdP which has no protocols in common with
>the SP.  

It could, yes. And certainly the DS needs a "go back with no answer"
option, I think. Which goes back to the error handling point, but that's
not the DS' job.

>The SP gets back an IdP which it cannot use and sending the user back to
>the DS will probably result in the same solution.  I suppose that at this
>stage it can throw up an error and let the user try again.

The assumption the SP makes is that the user doesn¹t get to try again, but
if you customized the error handling, it's possible to make it give the
user that choice. The SP does, however, handle the case of returning with
no selection. It does not re-dispatch to the DS, it falls through to
whatever is after the DS handler in the chain, usually nothing.

>The alternative is to put some filtering into the DS, but the potential
>complexity of this frightens me, particularly in the face of SPs not
>behaving as their SPs declare themselves to behave.

See previous comment about metadata.

>Note that none of this is (should be) an issue for the EDS - I believe
>that an SP can assumed to filter out IdPs with mutually different
>protocols.


Should but doesn't at the moment, mainly because the assumption is that a
2.x SP supports "everything". Currently mostly true, could be less true at
some point I guess. But I think I had it on my TODO list to add a metadata
filter that strips out based on protocol anyway.

-- Scott