shibboleth-dev - Re: comments: draft-mace-shibboleth-arch-protocols-02
Subject: Shibboleth Developers
List archive
- From: "Alistair Young" <>
- To: "Tom Scavo" <>
- Cc:
- Subject: Re: comments: draft-mace-shibboleth-arch-protocols-02
- Date: Mon, 22 Nov 2004 15:39:20 -0000 (GMT)
- Importance: Normal
I see now! You're correct Tom, in the use of "virtual students".
The Bodington VLE is unique (I think) in creating accounts on the fly and
we're currently extending it to talk to our SIS to properly set up the
account, with correct permissions etc. Our SIS is our primary information
store, from which a variety of online systems, such as the VLE, drive
their auto account creation.
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.
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!)
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.
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'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.
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 -
.
Thus "local/real" accounts at Oxford, such as "angus" can coexist with
"virtual" accounts such as
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
>> >
>>
>>
>
- Re: comments: draft-mace-shibboleth-arch-protocols-02, (continued)
- Re: comments: draft-mace-shibboleth-arch-protocols-02, Tom Scavo, 11/17/2004
- RE: comments: draft-mace-shibboleth-arch-protocols-02, Scott Cantor, 11/17/2004
- Re: comments: draft-mace-shibboleth-arch-protocols-02, Alistair Young, 11/17/2004
- RE: comments: draft-mace-shibboleth-arch-protocols-02, Scott Cantor, 11/17/2004
- RE: comments: draft-mace-shibboleth-arch-protocols-02, Alistair Young, 11/17/2004
- RE: comments: draft-mace-shibboleth-arch-protocols-02, Scott Cantor, 11/17/2004
- RE: comments: draft-mace-shibboleth-arch-protocols-02, Alistair Young, 11/18/2004
- Re: comments: draft-mace-shibboleth-arch-protocols-02, Tom Scavo, 11/18/2004
- Re: comments: draft-mace-shibboleth-arch-protocols-02, Alistair Young, 11/22/2004
- Re: comments: draft-mace-shibboleth-arch-protocols-02, Tom Scavo, 11/22/2004
- Re: comments: draft-mace-shibboleth-arch-protocols-02, Alistair Young, 11/22/2004
- Re: comments: draft-mace-shibboleth-arch-protocols-02, Tom Scavo, 11/22/2004
- RE: comments: draft-mace-shibboleth-arch-protocols-02, Alistair Young, 11/18/2004
- RE: comments: draft-mace-shibboleth-arch-protocols-02, Scott Cantor, 11/22/2004
- RE: comments: draft-mace-shibboleth-arch-protocols-02, Alistair Young, 11/22/2004
- RE: comments: draft-mace-shibboleth-arch-protocols-02, Scott Cantor, 11/17/2004
- RE: comments: draft-mace-shibboleth-arch-protocols-02, Alistair Young, 11/17/2004
- Re: comments: draft-mace-shibboleth-arch-protocols-02, Tom Scavo, 11/17/2004
Archive powered by MHonArc 2.6.16.