Grouper Developers Forum

[Chris Hyzer <>]

The example I was thinking of is if someone creates a group of all active 
people, minus students, who can access a service.  Then someone is 
reorganizing, and deletes the student group.  Now students do have access, 
but they shouldn't.  So the result is we open the access to more people than 
those who need it, or fewer.  Granted, I don't really think people will set 
up groups like this, so it doesn't seem all that realistic/common.

Your preference makes sense, and Im fine with it.  

I wonder if at some point we should have a notification (email) sent to 
someone alerting them of this.  Either site-wide, or you could register for 
events/errors on specific groups/stems.  At some point... :)

Chris



> -----Original Message-----
> From: Tom Barton 
> [mailto:]
> Sent: Tuesday, April 28, 2009 2:24 PM
> To: Chris Hyzer
> Cc: 
> 
> Subject: Re: [grouper-dev] add ability to delete a composite factor
> 
> Thanks for writing this up Chris. I want to argue for 3b and against
> 3a.
> Let's set the stage with a specific example.
> 
> Suppose I run a service, myService, to which access is restricted to
> members of a group called myServiceAllowed. Because of site policy, the
> network security folks maintain an emergency "shut them out"
> capability,
> one form of which is to disable access to services deemed important in
> this regard. So the myServiceAllowed group is actually defined as
> 
>    myServiceAllowed = myServiceUsers - securityShutOut
> 
> ie, everyone I'd like to use my service, less anyone currently being
> shut out due to the security policy.
> 
> One day the security people decide to delete the securityShutOut group.
> Whether to support some improvement to things or by accident, what
> should happen?
> 
> In case of 3a, myServiceUsers would be replaced with emptyGroup. I, as
> service provider, and all of the users that consider that service to be
> of value, will be very unhappy with this consequence of an action taken
> independently by another office.
> 
> That leaves 3b or fail with error as the remaining options. But fail
> with error was the problem to begin with: it requires coordination
> across independent parts of the organization to undertake something
> which might be of concern only to one. Not the worst thing in the
> world,
> but can be a big speedbump.
> 
> So that leaves 3b, which seems to be the most consistent projection of
> the "delete" metaphor that does not entangle unrelated concerns.
> 
> Others' thoughts?
> 
> Tom
> 
> Chris Hyzer wrote:
> > Right now if you try to delete a group which is a composite factor,
> > it throws an error.  We would like to handle this more gracefully.
> > Here is the proposal that the group team discuss at the member
> > meeting.  I left one decision in there, we had discussed 3b, though I
> > have a feeling that could be a security problem, and that 3a might be
> > more secure.  If anyone has thoughts let me know.
> >
> > https://bugs.internet2.edu/jira/browse/GRP-272
> >
> >
> > Add ability to delete a composite factor. Here is my proposal:
> >
> > Add a concept of an emptyGroup in the grouper.properties. Sites
> > should configure a location for this, e.g. next to the wheel group.
> > e.g. etc:emptyGroup. There should be a check that no members are ever
> > added this this group.  GrouperAll should be able to READ this group.
> >
> >
> > 1. If it is a union composite, and a factor is deleted, then replace
> > the unioned deleted factor with the emptyGroup
> >
> > 2. If it is an intersection composite: then replace the intersected
> > deleted factor with the emptyGroup
> >
> > 3. Complement. If it is the left factor, then just replace that
> > factor with the emptyGroup. If it is the right factor then we have
> > two choices:
> >
> > a. replace both factors with the empty list -or- b. just replace the
> > right factor with the empty list
> >
> > The right factor is the excludes list for a group, if that excludes
> > list is deleted (perhaps unbeknownst to the app using the composite),
> > I think the more practical thing to do (80/20 rule) is to just do
> > "b". However, that might unwittingly give more access to the resource
> > than was intended, so the most secure thing to do is to flag this as
> > an error condition by doing "a".
> >
> > Thanks, Chris