Grouper Developers Forum

[Tom Barton <>]

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.

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