Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] add ability to delete a composite factor

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] add ability to delete a composite factor

Chronological Thread 
  • From: Tom Barton <>
  • To: Chris Hyzer <>
  • Cc: "" <>
  • Subject: Re: [grouper-dev] add ability to delete a composite factor
  • Date: Tue, 28 Apr 2009 13:24:00 -0500

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?


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.

Add ability to delete a composite factor. Here is my proposal:

Add a concept of an emptyGroup in the 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

Archive powered by MHonArc 2.6.16.

Top of Page