Skip to Content.
Sympa Menu

grouper-users - Cascading into and out of groups and signet

Subject: Grouper Users - Open Discussion List

List archive

Cascading into and out of groups and signet

Chronological Thread 
  • From: Bert Bee-Lindgren <>
  • To: Grouper Users <>
  • Subject: Cascading into and out of groups and signet
  • Date: Mon, 3 Mar 2008 12:26:07 -0500

We have official data. (Slow, untouchable)
We have data on the ground. (Needs to be right or people can't do their jobs)
Sometimes we want both in groups.

Yes, we wish the official data were better, but it's never going to be fast or right enough. For example, HR just does care about adjuncts, collaborators, employee loans (that don't involve money), etc.

When I look at grouper, I don't see the richness of overrides that Signet offers, particularly, temporary or other conditions, proxying, etc.

So, do people typically have the following pattern?
HRMS Data: Faculty in History Department (updated at the speed of bureaucracy)
LDAP/IdM Store: Faculty in History Department (synchronized with
Grouper: HRMS:History:Faculty (official group, a good starting point, but limited usefulness)

Grouper: Departments:History:Faculty (group that can be tweaked by department to include adjuncts, other non-employed researchers/ collaborators, etc)
Signet: Departments:History:Faculty (departmental "membership" privilege that can be tweaked by department, but using temporary (etc) conditions)
Grouper: Departments:History:Faculty (group made from the above privilege that can be used by group-consuming systems)

In other words:
a) How do implementations deal with groups that need to be tweaked into other groups, when those tweaks benefit from signet's abilities?
b) Does anyone take all of signet's privileges and make them groups, just in case the Service-Providing system wants groups instead of attributes?


Archive powered by MHonArc 2.6.16.

Top of Page