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

["Alistair Young" <alistair@smo.uhi.ac.uk>]

Would it be feasible to use an AuthenticationRequest to transport the
domain suffixed ID that the user enters on the destination site?
The Bodington VLE has a separate page for external logins, as opposed to
local students going about their normal studies.
If a user, 1324@uhi.ac.uk, enters this ID, no scope for entering a
password, in the VLE's external login page, theoretically, the next page
they see is their ID, removed of it's domain suffix and an exhortation to
prove who they are, i.e. enter their password.
Their password is only ever seen by their SAML authority. If they need to
change their affiliation, say, they're registered somewhere else and have
accordingly separate access privileges, they just login with a different
domain suffix.
The destination VLE just packages up their ID in an AuthenticationRequest
and sends it to their domain suffix identified SAML authority for
authentication. The assertions can then continue as normal and the VLE can
commence to create them a local account using their fully qualified ID, to
prevent namespace clashes with other institutions.
We can guarantee that our student IDs are unique across our partner
institutions but we can't guarantee that they're unique. The domain suffix
should though.
As VLEs require local accounts, the user store could fill up with accounts
from many federated institutions.
It would seem that artifact resolving on the target side could possibly
provide a way for a SAML authority to gather information on what it's user
has done on the target side, for eLearning assessment etc.
Alistair



-- 
Alistair Young
Senior Software Engineer
UHI@Sabhal Mòr Ostaig
Isle of Skye
Scotland

>
>
> Tom Scavo wrote on 10/12/2004, 11:30 AM:
>
>  > On Tue, 12 Oct 2004 08:20:19 -0400, Conor P. Cahill
>  > <concahill@aol.com> wrote:
>  > >
>  > >    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.
>
> it *may* store past history.  It could store information about the
> current session of the uses.
>
> Yes, it *may* only store a subset of the enrollments (or it could
> have the full set)...
>
> Needless to say, this isn't perfect (especially in a model where
> cookies are disabled).
>
>  > >    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)?
>
> Actually it doesn't imply anything about the IDP at all.  It implies
> that the SP knows the IdPs that it's willing to accept assertions
> from and that the user knows which IdP it wants to use at this time.
>
> I believe most SPs will have a finite list of IdPs that they are
> willing to work with (or will be in a COT that supports some dynamic
> method for locating IdPs).
>
>  > >    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?
>
> This is an SSO request where the SP sends an SSO initiation request with
> the IsPassive flag set to true.  The SP can submit this according to the
> SSO profiles that it wants to support.
>
>  > >    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.
>
> no.  It implies that the SP has complete knowledge of the IdPs that it
> is willing to work with.  The Principal's enrollment will hopefully
> include at least one of those or else they can't do SSO.
>
>  > > 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?
>
> No.  The IdP discovery stuff is the kind of stuff that I have been
> talking about prior to this.  The last paragraph is more of an
> "IdP record" mode.
>
> The User can choose a different IdP via some UI on the SP or the
> SP could work in a non-automatic mode (where the user has to select
> the IdP it wants to use each time), or the user can control the
> IdP at the IdP's interface (e.g. configure the IdP to always ask
> before issuing the assertion so the user can say no for the IdP
> whose token she doesn't want to use).
>
> Conor
>
>
>