Grouper Developers Forum

[Joy Veronneau <>]

Hi Everybody,

We talked about this some more today.  It turns out that everyone  
agrees that there are some groups that we won't want even the  
helpdesk staff to be able to see.

From experimenting with version 1.0, it looks like:

- If a group does not have "read" and "view" privs, then a person can  
not see if they are a member of the group.
- If a group has "read" but no "view" privs, then people can see that  
they are a member of the group (regardless of their "read" or "view"  
privs for the group.)

So we are going to propose that we restrict the creation of groups  
without "read" privilege, so that people can see what groups they are  
a member of, except for a very few groups.  The helpdesk will either  
be able to ask the user to sign into the Grouper UI and look at their  
groups, and/or we may write a utility for the helpdesk to be able to  
do that.

In any event, this is better than what we have now.  Nobody can see  
what permits they have, and only very few people at the helpdesk can  
look at your permits.  The helpdesk would also like to be able to see  
"...and 4 secret groups" or something like that at the end of the list.

Joy


On Jul 25, 2006, at 11:43 AM, GW Brown, Information Systems and  
Computing wrote:

> --On 25 July 2006 09:03 -0500 Tom Barton 
> <>
>  wrote:
>
> > I've indicated how you can deploy grouper to meet your need, but I  
> > can
> > imagine it might be difficult to operate this way if there are many
> > different group managers using restricted groups - there's no  
> > guarantee
> > that they'll all follow the conventions above. Do you think  
> > that'll be
> > your circumstance, and that you'd really need some capability to
> > "override" the privilege assignments made by those with group  
> > management
> > authority?
> If the capability is required, it may be possible to customise the  
> UI to achieve it. One way would be to:
>
> 1) Write and configure a Servlet filter, which acts after the  
> LoginCheckFilter, and which replaces the default GrouperSession  
> instance with one for GrouperSystem - assuming some authorisation  
> test is passed i.e. membership of the helpdesk group.
>
> 2) Override any 'write' action in Struts-config.xml, with an action  
> which says 'This function is not available'.
>
> This would allow the user to browse any stems/groups. Using the  
> Subject Search tab would allow them to check memberships /  
> privileges for any subject.
>
> The advantage of this approach is that it can be achieved without  
> modifying the UI source. The disadvantage is that links would still  
> be provided for 'write' operations. However, it would only take a  
> little effort to 'enhance' the UI so that it would behave as if the  
> user only had read privilege, but for every group.
>
> > Tom
>
>
>
> ----------------------
> GW Brown, Information Systems and Computing