[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] IdP Discovery
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]