Shibboleth Developers

[Tom Scavo <>]

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