Shibboleth Developers

[Tom Scavo <>]

On Sat, Jan 1, 2011 at 2:35 PM, Cantor, Scott E. 
<>
 wrote:
>>
>>My hasty conclusion is that the '_saml_idp' cookie used by both the
>>Centralized DS (CDS) and the Embedded DS (EDS) is *not* the common
>>domain cookie (CDC), even though the two cookies have the same name
>>and value syntax.
>
> All I meant was that it has the same format and meaning.

Right, this needs to be clarified in the documentation. I've
encountered a couple of wiki pages that are too strongly worded, but
now I'm not sure I can find them again. I'll keep my eye out for this.

>>I realize the CDS is no longer the primary focus of development, but I
>>think it would be useful if the CDS implemented a common domain
>>writing service (CDWS) and a common domain reading service (CDRS), not
>>as suggested in the spec, but using a simple (passive) HTTP protocol.
>
> 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.

> but that's not possible.

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.

> It is not appropriate to allow for unconstrained
> overwriting of the cookie without any way to authenticate or protect that
> action, because that leads to phishing.

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 already know this but phishing is one reason why the 2-factor
authn feature of the IdP is so very important.)

>>Then the EDS could be configured to query the CDRS (if one existed) to
>>obtain hints about the user's preferred IdP(s) in other subdomains. Of
>>course the EDS could routinely invoke the CDWS as well, to provide
>>hints to other SPs.
>
> But the single federation case isn't common or interesting

That's a separate topic for another time, I think.

> so this turns
> into the same thing Ping was proposing with probes for a dozen or more
> cookies, and brings in the need for IFRAMEs and timeouts, and third party
> cookies, etc.

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.

>>I'm not entirely clear where discovery is headed (even though I've
>>read everything I can get my hands on) but it seems some interaction
>>between the EDS and the CDS is desirable. I don't think the latter is
>>going away any time soon.
>
> It isn't meant to be used, though, and any place it is used, the wrong
> thing is probably happening, probably because the alternative was too much
> work or not clearly documented.

I don't think so. You can't wish away distributed computing. There
will always be situations where a centralized service is appropriate
and desirable.

> 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 pretty much that
> simple, I think. (The exception is for cases where SPs are themselves
> related and sharing a DS by choice, but that's never going to be one
> federation's DS.)

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.

Tom