Grouper Developers Forum

[Bert Bee-Lindgren <>]

Tom,

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.

Thanks,
  Bert

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?
>
> Tom
>
> 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)