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: Scott Koranda <>
  • To: Tom Barton <>
  • Cc:
  • Subject: Re: [grouper-dev] grouper subject attribute security
  • Date: Sun, 7 Aug 2011 12:45:32 -0500

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

For what it is worth, I think science VOs are more likely to
want to write significant custom apps and be able to marshal
subject attributes via Grouper WS, since they may not already
have a rich IdM infrastructure (Grouper can go a long way to
providing that infrastructure).



> 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.
> Tom
> 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?
> Thanks,
> Renee
> 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
> (getMembers)…
> What do you think?  J
> Thanks,
> Chris

Archive powered by MHonArc 2.6.16.

Top of Page