Re: [security-services] IdP Discovery

[Greg Whitehead <greg.whitehead@hp.com>]

On 11/15/06 11:21 AM, "Scott Cantor" <cantor.2@osu.edu> wrote:

>> There are two use cases I have seen for using IdP Discovery,
>> and they are not compatible:
>> 
>> 1) The presence of an IdP in the _saml_idp cookie indicates that the user
>> has a valid session with the IdP, implying that an SP might use that IdP
>> for seamless SSO. This use case requires that the _saml_idp
>> cookie is a session cookie.
> 
> I think if you're reading that into the profile, you're reading something
> that isn't there. We don't have any discussion amounting to "you should
> clear the cookie on logout". Maybe that's implicit, but I don't think so. I
> think that the overall thrust of the profile (e.g. the part about
> maintaining a list of IdPs) is that it's not a session indicator at all.

It's not that you clear the cookie on logout, it's how you create the cookie
in the first place (as a session cookie or as a persistent cookie). We don't
say anything about that.

>> 2) The presence of an IdP in the _saml_idp cookie indicates that the user
>> has an account with the IdP, but not necessarily an active session. This
>> use cases requires that the _saml_idp cookie is a persistent cookie.
> 
> I think that's the intention.

If that's the intention then we definitely need errata.

>> The current specs support both use cases, obviously, but it's a nightmare
>> for deployers to ensure that all participants are managing cookies
>> according to the same policy.
> 
> This is one reason among many that it's a questionable approach altogether.
> 
>> Better, I think, would be if we had metadata to describe a "common domain"
>> or "circle of trust" that could communicate these options.
> 
> My position has been that there's no metadata about it mainly because
> there's no wire protocol. Since I think the intent of the profile was what
> you're calling #2 above, I guess I don't see there being much in the way of
> options to communicate.

You don't view communication through the _saml_idp HTTP cookie as a wire
protocol?

>> Even better, would be if we had separate cookies for the two use cases so
>> that they could co-exist.
> 
> Well, let me throw out there that my project is planning to produce a wire
> spec for discovery that is basically SAML independent. A common domain is
> not practical in most large scale deployments (IMHO) and we basically
> decided we had no choice but to do this. This is about all that Shibboleth
> 2.0 is including in the way of SAML extensions, other than some trust
> management stuff.
> 
> The protocol is quite simple, but it includes an isPassive flag that allows
> your first use case to be more or less supported, although at the cost of
> two round trips (one to discovery, one to the IdP) to find out no session
> was available.
> 
> Anyway, if there's support for standardizing something, I have no objection
> to submitting it, but I haven't pushed it because I didn't sense much
> interest here, despite the fact that IMHO a lack of discovery options is
> killing browser-based federated SSO. It also seemed as though people were
> resigned to this, and were just waiting for Infocard.

I can't speak for others, but I think that would be a great contribution.

-Greg

> 
> -- Scott
>