Shibboleth Developers

[Tom Scavo <>]

On Mon, 22 Nov 2004 11:59:22 -0000 (GMT), Alistair Young
<>
 wrote:
> 
> I'm not really following the virtual student scenario. I don't know if SIS
> users are fully qualified, most probably not and I doubt if any VLEs are
> directly linked to an SIS.

Perhaps your use case is different than the one I have in mind.  I'm
thinking of an institution that wishes to expand its course offerings
to include students at other institutions (i.e., virtual students). 
These students are not physically at the institution offering the
course but need to apply for admission (as a student) nonetheless. 
Once they've completed the application process (i.e., are in the
student information system), they may register for courses.

So a virtual student goes through the same motions (application,
registration, etc.) as an ordinary student except that a virtual
student never physically appears at the institution offering the
course, so a virtual student can not be positively identified. 
Consequently, one institution relies upon the other for positive
identification (upon which student credentials are issued).

> I was taking the lack of a domain qualifier on an ID as being in the
> "default" domain - i.e. a local student who doesn't use shibb to gain
> access to the VLE.
> The only time an ID is qualified, is if it's coming from another
> institution. In that case, the account is created at authorisation time in
> the VLE with a domain qualifier.

Your VLE has more responsibility than a typical eLearning system.  In
my experience, an eLearning system doesn't creates student accounts on
the fly.  Instead the student information is imported from an
authoritative source, namely, the student information system (or the
eLearning system has real time connections to SIS).  How else would
the institution fully account for all the students that are taking its
courses?

> The VLE shouldn't know anything about the remote SIS at that other domain.
> Rather, an info gathering agent will tie that ID to it's "origin" info
> when requested to do so.
> To the VLE, the ID is just another ID but with a domain suffix on it, e.g.
> 
>  and any additional info it requires to create an account,
> such as full name, email etc.
> Remember, the domain qualified ID is not an email address - it just looks
> like one :)

Yes, I think I understand what you're trying to do.  This is a nice
technical solution to the inter-institution access problem, but unless
I'm missing some key ingredient (which is likely :) I don't see how
this will satisfy the administrators (not system administrators but
the folks in the registrar's office).  The remote students you have in
mind must have a very informal relationship with the institution
offering the course.  Are your virtual students formally admitted to
the institution?  If not, how does the institution track what students
are taking what courses?

> Alistair
> 
> --
> Alistair Young
> Senior Software Engineer
> UHI@Sabhal
>  Mòr Ostaig
> Isle of Skye
> Scotland
> 
> > On Thu, 18 Nov 2004 08:41:52 -0000 (GMT), Alistair Young
> > <>
> >  wrote:
> >>
> >> In the VLE, we have to avoid namespace clashes. There may already be a
> >> joebloggs user account locally. All VLEs have local user databases
> >> AFAIK.
> >> So 
> >> 
> >>  would mark the user as external and coming in via
> >> shib.
> >> If they didn't, they'd continually get "invalid password" errors from
> >> the
> >> VLE as it thinks they're local.
> >
> > This is what I was referring to yesterday.  The "local user database"
> > feeds off an administrative student information system.  If the
> > usernames are fully qualified in SIS, then they're fully qualified in
> > the VLE and all is well.
> >
> > It is important that each student be represented in SIS, both students
> > and virtual students.  Otherwise there's no way for the institution to
> > keep track of who's taking what courses, and this information is
> > crucial for accounting and auditing purposes (i.e., it often
> > translates into $$$ for the institution).
> >
> > Cheers,
> > Tom
> >
> 
>