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

[Daniel Deng <dan6898@yahoo.com>]

--- Tom Scavo <trscavo@gmail.com> wrote:

> Hi Alistair,
> 
> Thanks for the note.  The Guanxi project sounds
> interesting.  Can you
> provide a reference?
> 
> If I'm understanding you correctly, assuming the
> identity provider is
> wholly contained within a single security domain,
> it's not necessary
> for the user to fully qualify their username when
> entering
> credentials.  Instead, the SAML assertion obtained
> subsequently could
> contain a fully qualified e-mail address.  Indeed,
> there is a
> predefined NameIdentifier with Format
> 
>
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
> 
> that does precisely what you want, I think.  The
> trick of course is to
> coerce your learning management system to identify
> users in this way.
> 
> 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?
> 
> 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. 
> 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.  The common
> domain cookie can be
> used to initialize the form controls that the user
> is asked to
> interact with, but that seems like the best we can
> do.
> 
> Just my two cents worth,
> Tom Scavo
> 
> 
> On Tue, 12 Oct 2004 09:28:46 +0100, Alistair Young
> <alistair@smo.uhi.ac.uk> wrote:
> > The new SAML2 spec seems very interesting. Lots of
> hard work involved
> > there I think so thanks to all for producing such
> a comprehensive
> > package. Also, thanks to Tom for clarifying a
> destination site first
> > profile. Tom mentions the introduction problem,
> where it's not easy to
> > find out where the user's source site and
> Assertion Service is located.
> > wrt this I'd be grateful for your opinions on a
> tentative solution that
> > we're playing with, on the Guanxi project.
> > We're building a SAML framework, based on
> Shibboleth and custom
> > implementations for eLearning, allowing students
> at one institute to
> > access resources on another institution's Virtual
> Learning Environment
> > (VLE).
> > SAML allows for privacy but also, in eLearning,
> student assessment is
> > critical, so there must be a way for the
> destination site to track the
> > progress of the user. This could be done
> pseudonymously using an
> > artifact or it could just know the user's source
> site ID. This way, the
> > introduction is done by the user, suffixing their
> source site ID with
> > their domain, i.e. 1324@uhi.ac.uk
> > I suppose that 1324@uhi.ac.uk is still a
> pseudonymous artifact that can
> > be used for tracking in the VLE and for creating
> an account for the
> > user in the VLE.
> > As the federation is all built on pre-arranged
> trust networks, the
> > domain suffix will kick off a process of
> assertions as soon as the user
> > tries to login to the VLE.
> > Obviously, the user should never enter their
> password at the remote VLE
> > but what do people feel about entering the domain
> qualified user ID and
> > using SAML2's authentication request structure to
> get the user
> > authenticated at their source site?
> > thanks,
> > Alistair
> > 
> > 
> > 
> > 
> > On 12 Oct 2004, at 03:45, Tom Scavo wrote:
> > 
> > > Here's an alternative profile to section 4.3
> that addresses the issues
> > > mentioned below:
> > >
> > > Browser/Artifact Profile, Destination-Site-First
> > >
> > > 1) The client accesses a secure resource at the
> destination site.
> > >
> > > 2) A security check causes the client to be
> redirected to the
> > > authentication authority at the source site.*  A
> target parameter with
> > > the URL of the secure resource is appended to
> the redirect URL.
> > >
> > > 3) The client requests the authentication
> authority as outlined in
> > > step 2.
> > >
> > > 4) The authentication authority challenges the
> user for credentials.
> > >
> > > 5) The user supplies the required credentials.
> > >
> > > 6) The authentication authority verifies the
> credentials, establishes
> > > a security context at the source site, and
> redirects the client to the
> > > inter-site transfer service along with the
> target URL.
> > >
> > > 7) The client requests the inter-site transfer
> service as outlined in
> > > step 6.
> > >
> > > 8) The inter-site transfer service redirects the
> client to the
> > > assertion consumer service at the destination
> site.  The redirect URL
> > > includes the target URL and the artifact.
> > >
> > > 9) The client requests the assertion consumer
> service as outlined in
> > > step 8.
> > >
> > > 10) The assertion consumer service requests an
> assertion from the
> > > source site's artifact resulution service.
> > >
> > > 11) The artifact resolution service returns the
> required assertion(s).
> > >
> > > 12) The assertion consumer service creates a
> security context at the
> > > destination site and redirects the client to the
> target resource.
> > >
> > > 13) The client requests the target resource
> (again).
> > >
> > > 14) The destination site performs a security
> check and returns the
> > > resource to the client.
> > >
> > > * This is the so-called "introduction
> problem"---in general, how does
> > > the destination site know the principal's
> preferred source site?
> > >
> > > Hope this helps,
> > > Tom Scavo
> > >
> > >
> > > On Mon, 11 Oct 2004 10:58:23 -0400, Eve L. Maler
> <eve.maler@sun.com>
> > > wrote:
> > >>
> > >> Thanks very much for taking the time to send
> these comments.  We can
> > >> try
> > >> to correct errors at some point, though
> obviously this isn't quite as
> 
=== message truncated ===