[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [saml-dev] SAML 1.1 Technical Overview (11 May 2004)
On Tue, 12 Oct 2004 11:19:04 -0400, Scott Cantor <cantor.2@osu.edu> wrote: > > By the way, this has nothing to do with the "introduction problem", > > which surfaces very early in the profile (step 2 below), that is, at > > the precise time the client firsts requests a secured resource at a > > service provider. Since no security context yet exists, the service > > provider must turn the client away and redirect to an identity > > provider...but which identity provider? > > Well, no, it doesn't *have* to turn the user away. It could collect all > sorts of input first, which I think it what Alistair is talking about. If I > enter a userid of some sort that can be reasonably used to map to my IdP, > then that's a solution, at some additional cost. At the cost of SSO, it seems, since now the user must enter credentials twice. > > The Identity Provider Discovery Profile in SAML 2.0 addresses this > > issue. However, it is vague as written (perhaps intentionally) and > > moreover it does not seem to solve the problem. > > I'm not sure why you think it's vague, but now is when we need feedback. I guess I'm missing something since I don't see the "profile" aspect of the Identity Provider Discovery Profile. I do see the precise definition of a (common domain) cookie, which is certainly useful, but it would also be helpful if the profile defined a sequence of events that solved the introduction problem in sufficient generality. I am probably missing something but the profile doesn't seem to do this as it stands. > It's the same as the Liberty CDC profile, and it's about as specific as it > needs to be, I think. It's not a perfect solution, but it's a relatively > useful piece of the solution. > > > Given that users may > > enroll with multiple identity providers, it is impossible to > > anticipate user wishes even with information about past behavior. > > Seems the only reasonable solution is to let the user select the > > desired identity provider every time. > > I think it's unreasonable to do that. Once maybe. But then you should offer > the option to remember the choice, and that's basically what the common > domain cookie does. > > Also, depending on the deployment, multiple IdPs per user might be a very > uncommon case, making it a poor choice to optimize. Points well taken, especially the "option to remember" idea. Thanks. > -- Scott Cheers, Tom Scavo
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]