Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] FERPA Protected Data

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] FERPA Protected Data

Chronological Thread 
  • From: "GW Brown, Information Systems and Computing" <>
  • To: Tom Zeller <>,
  • Cc: Thomas M Goerger <>, Kevin J ORourke <>
  • Subject: Re: [grouper-users] FERPA Protected Data
  • Date: Fri, 12 Sep 2008 07:59:29 +0100

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.


--On 11 September 2008 17:13 -0500 Tom Zeller

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 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.


On Thu, Sep 11, 2008 at 3:56 PM, Chris Hyzer

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 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)


-----Original Message-----
From: Thomas M Goerger
Sent: Thursday, September 11, 2008 4:45 PM

Cc: Kevin J ORourke
Subject: [grouper-users] FERPA Protected Data


We're running into situations where we'd like to be able to restrict
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
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
or if not, when might something like this be available?


* 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

Archive powered by MHonArc 2.6.16.

Top of Page