Re: [saml-dev] SAML 1.1 Technical Overview (11 May 2004)

[Tom Scavo <trscavo@gmail.com>]

On Tue, 12 Oct 2004 08:20:19 -0400, Conor P. Cahill <concahill@aol.com> wrote:
> 
> 
> Alistair Young wrote on 10/12/2004, 4:28 AM:
> 
> >  [detailed discussion about using a user provided identity handle
> >  as a means of "discovering" the location of the SAML Authentication
> >  authority]
> 
> Yes, this is a possible means.  Others, that I am aware of include:
> 
>    a) Common domain cookie (where the two (or more) sites use
>       a common domain to store one or more locations of
>       SAML authorities that have spoken for a user sitting in
>       front of the browser at some point in the past -- not
>       necessarily the current user).

Yes, but note that the common domain cookie stores past history, it
does not store all possible principal enrollments.

>    b) Scarab (not sure where the word came from) - where a site
>       places one or more icons on the login page indicating that
>       the user can select the icon representing their SAML
>       authority to use for this authentication.

This implies that the identity provider has complete knowledge of
principal enrollments.  Even if this were known to the identity
provider, how would it filter down to the level of the login page
(which is outside the scope of SAML)?

>    c) Search - when there is a very small set of possible
>       authorities, you can walk the list using passive requests
>       until you have success

How is such an algorithm bound to HTTP and how does it integrate with
an SSO profile such browser/artifact?

>    d) Drop down lists - the SP lists all of the possible
>       authorities in a drop down list.

This implies that the service provider has complete knowledge of
principal enrollments.  Even if this were known to the service
provider, it doesn't seem like the correct place to accumulate this
knowledge since it would have to be duplicated at all service provider
endpoints.

> I'm sure there are many others and many manifistations of those.

The WAYF service of Shibboleth strikes me as most usable.

> Note that once you have gotten an authentication, you can store the
> authority in a local cookie and/or in the URL so that subsequent
> access doesn't require the discovery process.

Yes, the Identity Provider Discovery Profile, but this assumes that
user behavior always follows past behavior.  What if the user wants to
use a different identity provider this time around?

> Conor
> 
> 

Cheers,
Tom Scavo