Shibboleth Developers

[Tom Scavo <>]

On Mon, 22 Nov 2004 15:39:20 -0000 (GMT), Alistair Young
<>
 wrote:
> 
> Now, however, you have pointed out the interesting case where remote
> students must appear in the SP's SIS, as virtual students. I'd just like
> to clear up any confusion I may have though - Virtual Students are
> students who are registered at one institution but are studying at
> another.

Basically, yes.  They are admitted to two institutions simultaneously
and also taking courses at both instituions.  Any given student is
most likely pursing a degree at just one institution (if at all) but
this may be relaxed, too.

Now the virtual student in the SP's SIS looks exactly the same as an
ordinary student except that the virtual student is not physically on
campus, may never be on campus, and therefore can not be positively
identified.  Thus the SP institution must rely on the IdP institution
for positive identification.

> Let's drop the on-site requirement as they may very well come on-site for
> a week's face to face perhaps, in the summer. Also, students who enroll in
> distance learning may never come on-site either but are registered at only
> the one institution so are not virtual students. (We have loads of them!)

Whether or not the student is physically on campus (even if for a
short while) is an important distinction.  If they are, they can be
positively identified by the SP institution at that time.  An SP
e-mail address and password could be issued at that time.

> So:
> angus, studying "Bagpiping 101" at UHI and studying module "A Quieter way
> to pipe" at Oxford = Virtual Student.
> 
> You're saying that the Oxford SIS must have 
> 
>  registered as
> a virtual student and marked as taking that module.

Exactly!

> Should this be driven by the primary data store, i.e. the UHI SIS? It
> seems that the Oxford SIS could make SAML requests for
> assertions/attributes to the UHI SIS, to create such a virtual account.

We need to distinguish student attributes required for access control
versus those attributes permanently stored in SIS (address, phone #,
SSN, SAT and ACT scores, transfer credit, etc.).  Virtual students
look just like students in SIS except that virtual students do not
have certain credentials such as an e-mail address and password to
access SP resources.  This is handled by Shibboleth.

> We're getting daring now. When 
> 
>  logs onto the Oxford VLE,
> not only is a SAML exchange required to authenticate/authorise, to create
> a VLE account but more SAML is required to give 
> 
>  a virtual
> presence in the Oxford SIS.

Well, yes, but this doesn't need to happen continually.  It need only
happen once.

> Now, as the VLE account creator module is driven by SIS data, then it
> would make sense for the SIS virtual account to be created first. Then the
> VLE just creates local accounts as normal, driven by it's SIS. The only
> difference it will see is the account is domain qualified -
> .

Precisely!

> Thus "local/real" accounts at Oxford, such as "angus" can coexist with
> "virtual" accounts such as 
> 

Now we're on the same page!

> thanks for making me think even more Tom :)

:-)

> cheers,
> 
> 
> Alistair
> 
> --
> Alistair Young
> Senior Software Engineer
> UHI@Sabhal
>  Mòr Ostaig
> Isle of Skye
> Scotland
> 
> > 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
> >> >
> >>
> >>
> >
> 
>