Grouper Developers Forum

[Tom Barton <>]

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