Shibboleth Developers

[Tom Scavo <>]

Hi Alistair,

So you intend to solve the IdP discovery problem by requiring users to
type their fully qualified username (i.e., e-mail address) of their
preferred IdP?  Yes, that's a fine solution.  However, it seems this
is a function of the WAYF, not the SP.  In fact, the "Identity
Provider Discovery Profile" section in the latest Shib Architecture
doc describes how the SP might interact with the WAYF to retrieve the
user's preferred IdP.  So you've essentially solved the IdP discovery
problem.

This is not what I was referring to in my previous message, however. 
Once the SP receives the authn assertion and the fully qualified
username (or whatever persistent identifier is agreed upon) from the
IdP, that attribute must correlate with a user known to the VLE.  Thus
the VLE must recognize users by the same persistent identifier.  So
let me stop and ask: how are accounts created in your particular VLE? 
What is the source of the "usernames" known to your VLE?

Thanks,
Tom

On Wed, 17 Nov 2004 14:55:35 -0000 (GMT), Alistair Young
<>
 wrote:
> For the username qualification, I proposed a domain suffix profile, where
> a user enters their qualified SIS (or other institution specific ID) but
> qualified by that institution:
> 
> in this way, the VLE knows that it must do "shibboleth" type things. If
> they enter "user", without qualification, the VLE assumes they are local
> to org2.
> In this way, any user can access any VLE in any org, just by "introducing"
> themselves as 
> user@org.
> SAML2 as AuthnRequest, or similar :) that could be used to strip the
> @org.ac.uk part from the username and send the "user" part of the username
> back to the IdP identified by "org.ac.uk".
> The SSO could be a known entity, that all partners in a federation decide
> to use, e.g. guanxi.org.ac.uk/SSO, or, they could choose to override this
> in metadata and the VLE will use that particular SSO URL instead.
> It does away with long lists of institutions/searching etc.
> In effect, it's an X509 distinguished name. Therefore, it could also be
> used by agents, which carry their own X509.
> Agents? We're looking at agents using shib/saml to do elearning things in
> a vle.
> The domain suffix IPDP just seems to fit the bill for users and agents.
> Needless to say, the password is only entered at the IdP side. Or, if
> trust is enough, in a federation, the password can be entered at the SP
> and sent back to the IdP in AuthnRequest.
> Alistair
> 
> --
> 
> 
> Alistair Young
> Senior Software Engineer
> UHI@Sabhal
>  Mòr Ostaig
> Isle of Skye
> Scotland
> 
> > Alistair has patiently described his use case here and elsewhere:
> >
> > http://lists.oasis-open.org/archives/saml-dev/200410/msg00004.html
> >
> > It's not clear if the VLE requires identity (as Scott wondered) but
> > I'll assume that it does, which generalizes the problem somewhat.
> > I'll also assume that the VLE obtains the identity of users from a
> > (local) authoritative Student Information System.  Blackboard, for
> > example, requires a username, which can be internal to the learning
> > environment or imported from SIS (via snapshot, e.g.).  I'd be
> > surprised if WebCT is any different. [Mark?]
> >
> > So in SIS there is a pointer to student identity, which is most likely
> > an unqualified username or netID.  This unqualified username in SIS is
> > the source of the problem.
> >
> > Suppose we have two identity providers (IdP1 and IdP2) each with its
> > own set of enrolled students:
> >
> > IdP1 SIS:
> > student <user1>
> >
> > IdP2 SIS:
> > student <user2>
> >
> > Suppose further that each IdP manages its own VLE (SP1 and SP2).
> > Since the usernames are unqualified in SIS (and hence, in the VLE), it
> > is difficult for user1 to access services at SP2 (as Alistair has
> > pointed out) and similarly for user2 at SP1.  If we qualify the
> > usernames in SIS (easier said than done) and each student enrolls with
> > the other IdP, we have instead:
> >
> > IdP1 SIS:
> > student 
> > <>
> > virtual student 
> > <>
> >
> > IdP2 SIS:
> > student 
> > <>
> > virtual student 
> > <>
> >
> > Assuming that the VLE obtains its users from SIS, both students and
> > virtual students are now uniquely represented in the VLE and the
> > problem Alistair is having (as far as I understand it) goes away for
> > the most part.
> >
> > In SIS, a student is identical to a virtual student except that the
> > latter has a virtual identity.  How does this virtual identity find
> > its way into SIS?  In addition to the normal positive identification
> > process (for local students at the home institution), a new online
> > process must be created for prospective virtual students at remote
> > institutions.  This new online process is protected by Shibboleth (of
> > course :).  When the prospective virtual student accesses the process,
> > authentication goes against the remote institution who asserts the
> > identity of the student, which is permanently stored in SIS at the
> > home institution.
> >
> > In short, a student has a positive identity whereas a virtual student
> > has a virtual identity asserted by an IdP possessing positive
> > identity.
> >
> > Hope this helps,
> > Tom
> >
> >
> > On Sun, 31 Oct 2004 14:16:33 -0000 (GMT), Alistair Young
> > <>
> >  wrote:
> >>
> >> >> The privacy issue must be considered here.  The whole point of
> >> >> federated identity solutions such as Shib and SAML is that the user
> >> >> need not identify him/herself at the SP.  By requiring an e-mail
> >> >> address, you've just blown the privacy issue wide open again.
> >>
> >> For static web pages, for example, Shibb/SAML is fine and the SP need
> >> not
> >> know the identity of the user. However, as we're implementing shib/saml
> >> in
> >> a VLE (bodington), we have to, at some point, deal with the issue of
> >> assessment. A tutor arranges access for their students at another
> >> institution's VLE. As part of such a distributed course, the tutor must
> >> be
> >> sure that the students have followed the prescribed course of content
> >> and
> >> where applicable, interacted with other students on a bulletin board,
> >> all
> >> at the remote VLE.
> >>
> >> Shib/SAML will get them into the VLE, with some Guanxi extensions to
> >> create a local user account for each one. However, for the tutor to
> >> assess
> >> their progress, the VLE must be able to track them in some way.
> >>
> >> It could track them using an anonymous ID that could be resolved by
> >> their
> >> IdP to a real ID, or it could use their real ID from the start.
> >>
> >> The domain suffix is an attempt to kill two birds with one stone - to
> >> facilitate IdP discovery and allow Guanxi to create a trackable, local
> >> user account in the VLE, for assessment purposes in eLearning.
> >>
> >> For normal, static or non-assessed content, we don't see a need to use
> >> the
> >> domain suffix. Rather, just use normal shibb/saml. It's just in the
> >> context of eLearning that we need a way to allow tutors in the domain of
> >> an IdP, to be able to gather assessment info on students at another
> >> domain
> >> SP.
> >>
> >> How they get that info is not a shib or saml problem but the initial
> >> environment for creating an ID to gather such data is greatly influenced
> >> by the shib/saml community and their opinions on trust within eLearning.
> >>
> >> In a lot of cases, the user's ID is an impersonal, numeric identifier. I
> >> could see privacy being catered for by having the IdP authenticate the
> >> real ID but then issue an opaque, permanent, IdP resolvable ID to the
> >> SP,
> >> which it can use to create a local user account in the VLE. The real ID
> >> being discarded by the SP after authentication at the IdP.
> >>
> >> I hope I'm not being too verbose but we have a lot to think about and
> >> we're keen to seek the views on our proposals from the SAML community.
> >>
> >> --
> >> Alistair Young
> >> Senior Software Engineer
> >> UHI@Sabhal
> >>  Mòr Ostaig
> >> Isle of Skye
> >> Scotland
> >
> 
>