Grouper Users - Open Discussion List

[Chris Hyzer <>]

So the current implementation of Grouper's privileges is like Oracle PLSQL 
execution security using "definer's rights" instead of "invoker's rights".  
Another way to think of it is Oracle View security, where each privilege 
includes the GRANT option (so if you grant a priv, the grantee can expose the 
view to others without the underlying privilege).  

Im thinking about how your proposal for a security scheme would work at Penn, 
where we are trying to only give access to groups on an as needed basis (few 
or no globally available [GrouperAll] groups).  If our groups are made up of 
other groups which are out of the user's control (for instance an 
intersection with AllFacultyStudentStaff), then each time a user grants READ 
on a group, then the user would need to make a report of all the underlying 
groups, find out who the owners are, and ask the owners to grant READ to the 
grantee as well.  This sounds like a large administrative burden.

When the grantee does not have the necessary underlying privileges, one of 
two things occurs.

1. The user just doesn't see the members of the underlying group (works for 
unions, not so much for intersections/complements)

-or- 2. The user's access to the group fails (this is what oracle does in my 
examples above)

I think you are suggesting #1 should occur, but I think this kind of silent 
failure will not be noticed until some end user has an access problem, at 
which time I think it would be difficult to trace all the group security 
rules to find out where the problem is.  Also I think the performance of #2 
is better than #1 since the access is Boolean instead of a gray area 
(different users see different member lists).

Currently Grouper's principal interface to the world is LDAP, and this kind 
of security is not easy (or perhaps not possible) to implement in LDAP.

Anyways, I would think if we did ever add this, we would need to do like 
Oracle where you grant READ or you grant READ with GRANT option, so you would 
have a choice.  And I think if there is an underlying access failure, then 
the READ of the group should fail with a descriptive message (#2 above).

> Thanks for explaining why you can't implement more granular access
> privileges at this time. It seems to me that the ban on adding VIEW
> groups is ultimately tied to more granular evaluation of access
> privileges as well.

I guess this statement is correct... assuming #2 above, a user could make a 
group with a member that is a group that user can READ, so the user wouldn't 
be able to READ their own group, but perhaps other users with the underlying 
access could.

Two more points: 

1. The simpler the security scheme, the more likely (and the easier) someone 
will be able to implement external security to Grouper (e.g. if you have a 
central privilege management system).  Right now the security in Grouper is 
managed with AccessAdapter and NamingAdapter interfaces, so it is possible to 
externalize.

2. I would like to point out that complex security schemes (i.e. two flavors 
of READ privilege) are great for fine grained privilege management, 
especially for the people who create the system.  However, it is also 
generally very difficult for end users to understand, to use correctly, and 
to administer without training or spending lots of time.  Penn has a 
hierarchical privilege management system where you assign privileges as 
ALLOW, DENY, or INHERIT from the parent node (sounds simple enough, right?), 
and this is *constantly* a problem with end users to explain how the thing 
works; and we find setups where the user thinks they did the right thing, but 
in fact there are security issues with the setup.

> I hope you will keep these ideas in the suggestion
> box for possible future implementation.

Always.  :)

Thanks!
Chris


> 
> Paul Gazda
> 
> -----Original Message-----
> From: Tom Barton 
> [mailto:]
> Sent: Thursday, April 09, 2009 3:06 PM
> To: Paul Gazda
> Cc: Chris Hyzer; Grouper Users Mailing List
> Subject: Re: [grouper-users] RE: Access privileges within sub-groups
> and composite groups
> 
> Paul,
> 
> Regarding your first point, there is a major downside - the performance
> hit that would accompany implementing your proposal. Evaluating privs
> per membership, across an arbitrarily complex web of groups, will be
> far
> costlier than doing so at the group level, as at present.
> 
> So, as a pragmatic matter, rather than as a conceptual matter, I have
> trouble with your proposal. To achieve the purpose with reasonable
> performance sounds like an allocation of project resources that would
> seriously reduce our ability to deliver more important capabilities.
> 
> Regarding your second point, some time back we fixed the *bug* of VIEW
> being sufficient to add a group to another group. That allows anyone
> with VIEW to gain READ, in effect, by creating an empty group, then
> adding a group for which they only have VIEW as a member, then looking
> at the indirect members.
> 
> Tom
> 
> Paul Gazda wrote:
> > Chris,
> >
> > Thanks for your reply, although it is not what I was hoping to hear.
> J
> >  From the jira, it appears that there were technical factors
> > contributing to the decision, and I realize that the issue of
> changing
> > permissions on subgroups presents dilemmas no matter how you handle
> it.
> > However, I do want to present arguments for having Grouper
> dynamically
> > honor access permissions when displaying query results, and allowing
> > subgroups with view privileges to be added.
> >
> >
> >
> > First, dynamic evaluation of permissions. If a person creates a group
> > with "read" access to GrouperAll, and other people incorporate it
> into
> > their groups, and then the person changes access to "view" for
> > GrouperAll, they would intuitively expect from that point on, that
> > people would not be able to see the members of that group. They would
> > not be thinking that the previous read privilege would be
> grandfathered
> > into all groups that currently have it as a subgroup. If the burden
> is
> > placed on the business logic of the UI, it could generate a lot of
> > overhead for the admin user behind the scenes to look for all groups
> > that contain the subgroup and delete it from all of them. That could
> be
> > a very time consuming operation using web service calls.
> >
> >
> >
> > I also see an advantage of allowing subgroups to be added when the
> user
> > has only view access. For example, some standard groups may be
> provided
> > to users such as all students, all staff, all faculty, etc. that may
> > have thousands of members. If everyone needs read access to use them
> as
> > subgroups, they will be able to query the members, and curiosity
> being
> > what it is, many people will be bogging down response time by
> needlessly
> > listing the thousands of members. The UI will have to prevent those
> > kinds of queries via business logic, which probably means both
> special
> > group design and special coding to recognize and suppress the
> querying
> > of those special groups. It would be much simpler from a development
> > point of view if Grouper returned only the group name to a user who
> had
> > only view privilege at the time of the query.
> >
> >
> >
> > Paul Gazda
> >
> >
> >
> > ---------------------------------------------------------------------
> ---
> >
> > *From:* Chris Hyzer 
> > [mailto:]
> > *Sent:* Wednesday, April 08, 2009 12:05 PM
> > *To:* Paul Gazda; Grouper Users Mailing List
> > *Subject:* RE: Access privileges within sub-groups and composite
> groups
> >
> >
> >
> > That was a design decision...
> >
> >
> >
> > If you add a group's members to your group while you have read
> access,
> > then that group "has" those members, and can always query for them if
> > you can list the outer group's memberships.  However, if you remove
> that
> > group from your group, then you wont be able to re-add it without
> READ
> > of the underlying group.
> >
> >
> >
> > So... if you are removing READ from a group, and you want to make
> sure no
> > one is using that list, you should check to see where that group is a
> > member of another group or a composite factor...
> >
> >
> >
> > We did discuss this on a design call, but this exact issue didn't
> make
> > it into the Jira issue, I added a comment.
> >
> >
> >
> > https://bugs.internet2.edu/jira/browse/GRP-199
> >
> >
> >
> > OK?
> >
> >
> >
> > Thanks,
> >
> > Chris
> >
> >
> >
> > *From:* Paul Gazda 
> > [mailto:]
> > *Sent:* Wednesday, April 08, 2009 2:55 PM
> > *To:* Grouper Users Mailing List
> > *Subject:* [grouper-users] Access privileges within sub-groups and
> > composite groups
> >
> >
> >
> > I am seeing what seems to be an inconsistency in the way Grouper
> handles
> > access privileges in sub-groups and composite groups. I have looked
> in
> > the listserv archives and wiki and could not find info on this. I see
> > the same behavior in both cases and will explain it with a sub-group
> > example.
> >
> >
> >
> > I have a group A.
> >
> > I have a group B.
> >
> > I make group B a sub-group of group A.
> >
> >
> >
> > I query for the members of group A using getMembersWs of
> GrouperClient
> > 1.4.1 as a non-admin. I see all of Group A's members plus Group B
> plus
> > Group B's members - as expected.
> >
> >
> >
> > I remove read and view access privileges on Group B for GrouperAll.
> >
> >
> >
> > I query for the members of Group B and get an error that the group is
> > not found - as expected.
> >
> >
> >
> > I query for the members of Group A and see all of Group A's members
> plus
> > Group B plus Group B's members. That is not what I would expect. I
> would
> > expect to see only Group A's members because Group B should still be
> > invisible to GrouperAll.
> >
> >
> >
> > Paul Gazda
> >