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

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[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]