Grouper Developers Forum

[Scott Koranda <>]

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

Sincerely,

Scott

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