Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] grouper subject attribute security

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] grouper subject attribute security

Chronological Thread 
  • From: Jim Fox <>
  • To: Tom Barton <>
  • Cc:
  • Subject: Re: [grouper-dev] grouper subject attribute security
  • Date: Mon, 8 Aug 2011 11:26:54 -0700 (PDT)

At UW we present only enough user attributes to enable a user to
distinguish between members with similar names: first name, last
name, department, affiliations. For students who have requested
their directory information be withheld the user must have special
permission to see even those attributes. Generally that means the
user is a staff person.

It seems a stretch to me as well to imagine grouper as a general IdM.
There are, or ought to be, other tools for that.


On Sun, 7 Aug 2011, Tom Barton wrote:

Date: Sun, 7 Aug 2011 09:47:05 -0700
From: Tom Barton

Subject: Re: [grouper-dev] grouper subject attribute security

First, I didn't respond only because of lack of time.

If I understand correctly, you propose to expose subject attributes by means
of grouper WS, respecting authenticated WS user's entitlements to
view subject attributes.

Narrow response for uchicago: we have limited custom apps using grouper WS,
though more are on the way. So far this need hasn't arisen, perhaps
because in our environment it's easy to look up subject attributes
constrained by authenticated user's entitlement, most often using ldap though
DB views are sometimes used.

Broader response. I'm guessing you're trying to make writing custom apps
easier by providing more capabilities through grouper WS interface, so
that apps don't need to include even more APIs (especially if they don't
already exist!). Nothing wrong with that per se. But the prospective
value to an adopting campus depends on their overall IdM and integration
capabilities. How many campuses are there that write significant custom
apps yet can't marshal subject attributes in those apps? I don't know, but
suspect that's an unusual situation.

This smacks of the type of consideration we might have at the osidm4he f2f in
a couple of days. This could be an example of a capability for which
we'd like there to be a standard API, and then that API can be interoperably
implemented in one or more IdM products. The Subject API and related
capabilities ought to be near the top of that list, IMO.


On 8/5/2011 9:31 AM, Renee Shuey wrote:
Chris et All,

Obviously, I find this very interesting.  I am curious why no one
responded to this message.  Is it because folks didn't really
understand exactly what this might mean for their environment or simply
because they know they are not at all interested.  Would be
helpful to me to learn more about why folks didn't respond.

Anyone have thoughts they are willing to share?

On 7/26/11 3:16 PM, Chris Hyzer wrote:

At Penn we are developing similar to what Penn State is working
on, user attribute security with SQL data views.  i.e.
users (subjects ) have a lot of attributes in our IdM, and we
want to preprocess them, and have them available for
consumers.  E.g. the various names, emails, affiliations, some
source-specific data (title/major), etc.  We have 130
columns in the data view.  These need to be secure at a column
and row level (e.g. an application could get access to see
employee data, but not student data, and only certain columns
e.g. not ssn).  Therefore this is not really conducive to
our LDAP deployment.  Right now we are planning on a SQL
implementation using Oracle VPD/FGAC.  The permissions will be
modeled as Grouper permissions and provisioned into security
tables for VPD/FGAC to use.


We have a handful of Grouper sources.xml subject attributes
available (name, email, netId, etc).  However, I think it
would be nice if these extra attributes could be available in the
Grouper getSubject (only) web service.  This is
optional, and would be dynamic, and protected by Grouper
permissions.  This is a very minor tweak, it would be is a Java
interface where you could write code to match up the request, and
the authenticated subject, and get the data for the
response based on security.  Grouper would not store or manage
these attributes, just like it is now.  I know Grouper is
not an IdM, but I think optional plugins where gaps in
institutions’ IdM exist could be useful.  The next step (don’t need
this now, but we can discuss later) could be to extend this to
the sources.xml subject attributes so that those can be
managed a little more closely across the other Grouper operations


What do you think?  J





Archive powered by MHonArc 2.6.16.

Top of Page