Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] What Georgia Tech is doing (missed call)

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] What Georgia Tech is doing (missed call)

Chronological Thread 
  • From: Bert Bee-Lindgren <>
  • To: Tom Barton <>
  • Cc: Grouper Dev <>
  • Subject: Re: [grouper-dev] What Georgia Tech is doing (missed call)
  • Date: Wed, 25 Jun 2008 15:20:02 -0400


Calling GRS a loader misses that the Grouper GUI/API changes (or goes away or gets augmented and put atop GRS DB) so that the GRS+Grouper system has
-Unified logging/auditing of manual actions along side loader-based decisions (one place to go)
-Ability to define expirations (time or data) for manual actions (member for 2 weeks)
-Ability for loader to (optionally) expire a manual action when the loader agrees with it (early-arriving faculty)
-Ability for loader to not re-add someone who was manually disabled
-Ability to see all the current reasons for a membership... (2 rules (employee and a student) and a negative override (service abuse))
-A UI to see upcoming expirations of grace periods and other timers under control of loader (students keep email for 6 months)
-other aspects not on the top of my head

It became clear in an earlier grouper (?) call that some people feel that this is signet responsibility. I agree that it is closer to signet than historic grouper, BUT we need all this functionality for group memberships. And signet's current position separate and downstream of grouper doesn't fit the boolean (aka group) memberships that comprise 85+% of our authorization requirements.


On Jun 25, 2008, at 2:43 PM, Tom Barton wrote:

Thanks Bert. I read this as being a very nice loader (so long as you're still doing boolean memberships). But does that description miss something important?


Bert Bee-Lindgren wrote:
Unfortunately, I couldn't make today's call, but I saw the agenda topic "what people are doing." I thought I'd take the opportunity to summarize Georgia Tech's activities since the meeting in Washington.
We have completed development of, and are wrapping up alpha testing of, a GT Role System (GRS). We're expecting it to be in customer hands in July for testing and August for production for limited customers. At some level, you can equate Role == Group.
GRS's initial, accomplished design goals include the following major items:
-Loader: Rules to match against subject sources (LDAP initially) and automatically add & remove subjects from roles
-Loader: Grace periods associated with enabling rules
-Admin UI: Full role/role-hierarchy/rule/access-control management
-Admin UI: Manual overrides to add/remove subjects from roles... with (optional) automatic reversal of override at a future date or based on subject's data or roles
-Access control: what role-memberships enable viewing/changing/ overriding/etc which other roles or role-hierarchy points
-Audit: Permanent history of subjects' relationships with roles (permanent as long as role exists)
Relationship to Grouper:
Technical relationship today: none
Possible relationship:
Right now GRS roles are boolean memberships and map very well into publishing them into grouper groups.
If this were to change from boolean memberships to parameterized memberships (quota, scope, etc), then those details would not publish well into grouper
Medium-term plans (Now-Dec):
Go into initial production without integration with Grouper
See if early i2mi interest in GRS means that Open Sourcing GRS is valuable to community
If so, use Chris's loader as a template on how to tie GRS Role- memberships into grouper
Why tie GRS and Grouper together:
Unified operation (UI, auditing, membership life cycle) for both automatic and manual ways subjects are added to, or removed from, groups
Temporary manual actions
Leverage Grouper as initial place for group publishing (ldappc, group algebra(?), etc)

Archive powered by MHonArc 2.6.16.

Top of Page