Skip to Content.
Sympa Menu

grouper-users - RE: [grouper-users] RE: Subject ID

Subject: Grouper Users - Open Discussion List

List archive

RE: [grouper-users] RE: Subject ID


Chronological Thread 
  • From: Chris Hyzer <>
  • To: Peter Schober <>, "" <>
  • Subject: RE: [grouper-users] RE: Subject ID
  • Date: Thu, 23 Feb 2012 14:11:31 +0000
  • Accept-language: en-US

At Penn each person has a unique university and a unique netId and a unique
eppn. One person cannot have multiple netIds.

So... if you have a situation where a person has multiple netIds, then you
need to decide if any one of the Ids can get access to the same services, or
are you securing different services to different netIds. I would think
generally the security is to the person, where you don't care which netId,
but maybe there is a use case for the other way around. If you want
different netIds to have different access, then each netId would relate to a
subject (either as subjectId or different person ids or whatever). If you
want them all tied together to the person, then any netId would resolve as a
subject identifier to the same opaque subject id, that should be fine.

Right?

Thanks,
Chris

-----Original Message-----
From:


[mailto:]
On Behalf Of Peter Schober
Sent: Thursday, February 23, 2012 3:01 AM
To:

Subject: Re: [grouper-users] RE: Subject ID

* Chris Hyzer
<>
[2012-02-22 21:00]:
> We use an 8 digit university ID which never changes. People are
> resolvable by identifier by netId and eppn, which could change if
> they change their name when getting married/divorced/etc

Is that "university ID which never changes" specific per person or per
account/netid/userid? If we were to introduce such an identifier I
guess we would want it to be unique to a person, to tie together all
her accounts/netids, allowing for name changes common to all netids,
etc.
But I suppose this is not what grouper would consider as a suitable
subjectId -- Grouper would want a unique id per netid/account/login
name, right?
-peter



Archive powered by MHonArc 2.6.16.

Top of Page