Shibboleth Developers

["Cantor, Scott E." <>]

>>In other words, you want to get around the rules for cookie access
>
>You could say that, I suppose, but it's a gross mischaracterization of
>what's being proposed.

No, I think it's exactly what you're doing, and it has technical
implications, particularly when you by necessity generalize it to the
reality that there is no single shared federation domain.

The Google solution to this was xauth (just trust us and put all your
information in our domain). The world rightly laughed at that idea.

>Sure it is. The SAML V2.0 Identity Provider Discovery Protocol is an
>existence proof. In that case an SP queries a centralized DS for an
>entity ID stored in a cookie on the user's browser. The CDRS is
>essentially the same thing.

And it doesn't scale to more than one DS domain, and it doesn't allow for
writing to that cookie from outside the domain. Andreas wanted it to, and
I refused, on the grounds that it required adding a security stack to the
protocol to avoid unconstrained control over the cookie to any malicious
web site that wants to seed hints (or in many cases today, silently cause
the DS to choose an IdP based on a single hint).

>All redirection protocols have that problem. SAML Web Browser SSO and
>the Identity Provider Discovery Protocol mitigate this danger by
>referring to metadata for trusted endpoints. I don't see how this is
>any different.

You can't constrain the ability to write to the cookie based on endpoints.
You have to authenticate the message, which means signatures and replay
detection (and therefore state). All to non-solve a non-problem for the
general case of SPs accepting users from many federations.

>> But the single federation case isn't common or interesting
>
>That's a separate topic for another time, I think.

No, it is a major reason why I continue to reject this idea. It can't be
separated from the discussion. It is the reason I would tell you to take
this up with refeds and come back when everybody in the world agrees on
the common domain to use.

>Huh? I'm not following you. At the protocol level, this implementation
>of the common domain concept is essentially equivalent to the SAML
>V2.0 Identity Provider Discovery Protocol. In fact, you can think of
>it as an extension of that protocol.

Yes, one that I refused to support originally.

>>We are not trying to provide for cross-SP hints.
>
>As I've said, your own contribution in this area (i.e., the SAML V2.0
>Identity Provider Discovery Protocol) does exactly that.

It's meant to be used in conjunction with the *SP*, not a federation. If a
set of SPs share discovery requirements, then they can share the hint.
That is not the case for most SPs that aren't run as part of the same set
of services. It works well for a VO, for example.

It's also not a hint sharing tool. It's a *discovery* sharing mechanism;
the whole process, not just a hint.

>Well, I'm hoping that you're simply misunderstanding the proposal
>(some of your comments indicate this is likely), so I think I should
>just write this up so at least we know what we're throwing darts at
>:-)  I'll do that asap.

I fully understand the proposal, it's not new.

Leaving the security implications aside, it only works if you share a
single domain for everything, or you build a mess of javascript and frame
hacks to probe multiple domains without causing the service to fail if any
of them are down.

-- Scott