Grouper Users - Open Discussion List

[Thomas M Goerger <>]

As far as we're concerned the role a person holds within the group has no
bearing on whether or not they would be able to see a suppressed entry.
The administrator should not be able to view personal information on a
suppressed entry any more than a member of the group would.  In many of
our scenarios, a group administrator has not necessarily been vetted to be
able to view personal information.

As a scenario, say, a department has tasked a student worker to maintain
group membership for staff members.  One of the staff members has set
suppression on their directory entry.  This job activity is seen as a data
entry task, but under the current set up, this student worker would have
to be cleared to view personal information.  We'll potentially have many
setups like this, and have to have many people cleared for this access,
which is cumbersome, to say the least.

Ideally, an administrator would be able to add any user to any group
whether they are suppressed or not, but once they are in that group, their
entry should be anonymous.  What I'm thinking is that perhaps there would
be some attribute set on the LDAP side that if populated, tells Grouper
that this entry is suppressed.  This value being set would result in any
personal information about this user to be set to <<Anonymous User>>
within Grouper, or something to that effect.

Hope this makes what we're looking for clearer, anyway.  Please feel free
to send questions or problems.

Thanks,

*********************************************************************************
* Tom Goerger                                  Email/Unix System 
Administrator  *
*                                                                             
  *
* University of Minnesota                      Email:  

         *
* Operations, Infrastructure and Architecture  Phone:  4-5804                 
  *
* Internet Services                            Office: 750 University Park 
Plaza*
*                                                                             
  *
*********************************************************************************

On Fri, 12 Sep 2008, GW Brown, Information Systems and Computing wrote:

> This has been discussed before but I don't know that we got clear
> requirements. Given that the Subject API may be used in other systems -
> Signet at least that we know of - a Subject API solution would be better
> than a Grouper specific one.
>
> The fundamental question must be: what rules governs who can see FERPA
> suppressed entries and where are they implemented? Should the rules,
> somehow, be built into the directory?
>
> We have talked in the past of source adapters being 'aware' of who is doing
> lookups/searches so that the repository would be in a position to apply
> filters / make subjects anonymous.
>
> Would we expect FERPA suppressed entries to appear at all - even
> anonymously - in member listings displayed for unprivileged users? The API
> would need to get something back in order to do membership calculations,
> but an API client could then suppress anonymous subjects.
>
> I'm sure we can come up with a solution if we can flesh out the use cases.
>
> Gary
>
> --On 11 September 2008 17:13 -0500 Tom Zeller 
> <>
>  wrote:
>
> >
> > Perhaps we could mark subjects as hidden or invisible (based on attribute
> > existence or value) so they are not displayed by the UI, e.g. in
> > media.properties: subject.don't-display.attr=FERPA or
> > subject.hide.attr=FERPA, subject.hide.value=true. Could be applied to a
> > group (e.g. a course) subject to hide all members, or to particular
> > subjects (e.g. a student who has requested FERPA). Maybe only applicable
> > to specific privileges, e.g. not ADMIN.
> >
> >
> > TomZ
> >
> >
> > On Thu, Sep 11, 2008 at 3:56 PM, Chris Hyzer 
> > <>
> > wrote:
> >
> > I don't remember an open Jira issue about this.  It can sort of be done
> > in 1.4 (coming out in Oct/Nov) with hooks.  You could configure your list
> > or regex of folders (in grouper.properties or some config file) such that
> > if a group is created under it (or edited if you like), that it will
> > unassign the EveryEntity read or list privileges.  If there isn't a
> > better way to do this (anyone?) we could consider a grouper-built-in hook
> > like the group attribute validators... shouldn't be too difficult.
> >
> > I don't know of a way to add a "type" or some flag to folders, so a
> > sysadmin would need to configure which stems or regexes are private.  If
> > you did a regex (substring), then if your stem name has a certain
> > substring then it would match, or maybe some certain substring in the
> > description.  Another way to flag is making a 'marker' group with no
> > members (e.g. called "school:etc:nonPublicRead"), and if that group has a
> > privilege against a folder, it is "marked".  Doesn't sound ideal...  but
> > just trying to think if it can be done without too large of a change
> > (e.g. stem metadata)
> >
> > Thoughts?
> > Chris
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Thomas M Goerger 
> >> [mailto:]
> >> Sent: Thursday, September 11, 2008 4:45 PM
> >> To: 
> >> 
> >> Cc: Kevin J ORourke
> >> Subject: [grouper-users] FERPA Protected Data
> >>
> >> Hi,
> >>
> >> We're running into situations where we'd like to be able to restrict
> >> the
> >> ability for group members to see FERPA suppressed entries.  We've just
> >> turned off the read attribute for now, but this is less than ideal, of
> >> course.  I'm seeing from list archives that you might have been working
> >> on
> >> the ability to see a FERPA flag on a directory, and set suppression on
> >> this entry according to this flag.  Has there been any progress on
> >> this,
> >> or if not, when might something like this be available?
> >>
> >> Thanks,
> >>
> >> ***********************************************************************
> >> **********
> >> * Tom Goerger                                  Email/Unix System
> >> Administrator  *
> >> *
> >> *
> >> * University of Minnesota                      Email:  
> >> 
> >> *
> >> * Operations, Infrastructure and Architecture  Phone:  4-5804
> >> *
> >> * Internet Services                            Office: 750 University
> >> Park Plaza*
> >> *
> >> *
> >> ***********************************************************************
> >> **********
> >
> >
>
>
>
> ----------------------
> GW Brown, Information Systems and Computing
> 
>