Grouper Users - Open Discussion List

["Cramton, James" <>]

I don't believe it is the responsibility of the group management tools
to determine who is active or not. Other systems upstream determine that
before our Grouper system can. More specifically, the authentication
system (Kerberos, LDAP, etc.) screens out the actives from inactives
according to person provisioning rules, so inactives can't authenticate
in the first place, so they can't be authorized by our groups
infrastructure. Additionally, our business systems send us feeds of
group membership in groups like BROWN:COMMUNITY:ALL, and these feeds do
not include users who are no longer active. That said, nomenclature is a
bit of a problem here, because we have a separate status for the kind of
users who are not currently engaged in university life, like students or
faculty on leave. We call these users "inactives." So the example of
former employees with a legitimate need to  use electronic resources
would be an "Active" user at brown--perhaps not faculty or staff, but an
affiliate of some sort.

At Brown, Grouper uses a local SQL person registry within the grouper
schema in Oracle. This was originally intended to handle Grouper 1.2 era
unresolvable subject exceptions, but it is also used as an aid to
reconstruct historical group memberships, which we sometimes need to do.
As folks become inactive in our person provisioning, they remain in LDAP
for 30 days, in a "DELETED" status. This allows for quick account
restoration in the event of the inevitable mistakes in paperwork, etc.
that cause people to accidentally become inactive.  This impacts our
nightly provisioning of the grouper person registry because as they
remain in ldap, they are flagged in the grouper registry with their LDAP
status--"DELETED." Once they drop out of the authoritative LDAP
registry, we leave them in the Grouper registry in their last known
state--"DELETED." We are in effect capitalizing on the fact that
upstream user and group feeds immediately forget about inactive users
and groups to hold onto an historical snapshot of group memberships in
historical groups. This allows us to quickly review, for example, the
members of a course group as it stood at the end of the term 2 years
ago. It's not a common use case, but it's one that comes up
occasionally. And so far, the populations in the database pale in
comparison with the other table sizes in the Grouper schema, so we have
not had need to purge old records. 

One use case where we've counted our lucky stars that we have visibility
to deleted users in Grouper is where there's a question of "why can't I
log in?"  These kind of questions often get past several layers of
helpdesk staff and land on my desk, where I can tell at a glance in
Grouper that they are flagged as inactive or deleted. If they were
unresolvable, I'd be left with ldap queries to find answers. "The more
Pooh looked, the more Piglet wasn't there."  

James Cramton
Lead Programmer/Analyst
Brown University




> -----Original Message-----
> From: Chris Hyzer 
> [mailto:]
> Sent: Monday, April 20, 2009 2:04 PM
> To: Grouper Users Mailing List
> Subject: [grouper-users] who is in your subject source?
> 
> Hey,
> 
> At Penn we have a subject source which has active Penn people.
> 
> Though it seems like apps need more than this (temp employees who
still
> need access, managers who need to gracefully transition away when they
> leave their job, researchers who aren't at Penn anymore, but still
need
> access to some resources to work with colleagues).
> 
> How do other schools define your subject source for people at your
> institution?  Only actives?  Everyone in your system even if they were
> inactivated 10 years ago?  Active people, and people who were recently
> inactivated?
> 
> Im not sure what the pros and cons of these are.  There was an extra
> security benefit to inactives becoming unresolvable, but it seems like
> it is not something that should be relied on.  Also, it would be hard
> to find people if there are hundreds more John Smiths in there...
other
> than that, I don't see a huge downside to opening up the subject
> source.
> 
> Thoughts?
> Thanks!
> Chris