OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [security-services] IdP Discovery


> 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.

> 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.

> 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.

> 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.

-- Scott



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]