Grouper Users - Open Discussion List

[Tom Barton <>]

Chris,

I didn't notice any replies reflecting actual practice in this regard, 
so let me give some different perspective.

You identify what I think are two more-distinct-than-not use cases 
below. One has to do with multiple local Subject sources and the other 
has to do with managing "federated Subjects" in grouper. In both cases I 
want to avoid making grouper-specific accommodations, since these are 
general issues, not bearing primarily on group management.

The Subject API already provides a solution for the first use case. Is 
there some shortcoming of that approach that we should address?

There is indeed something missing to support the second use case. It can 
be done by providing another Subject source in which the federated 
Subjects of interest have been collected by some other application, but 
that other application isn't available off-the-shelf. I think you're 
suggesting that grouper be that application.

The second use case, however, is far more general than grouper. One of 
the issues it presents is the "introduction problem": how do I find out 
what federated identifier your sessions on my resources will have, so 
that I can manage your access to them? Another problem is where to store 
the few bits of info kept on federated Subjects so that they can be used 
by all of the local applications serving a federated population.

Others are working these problems and it'd be great to rely on what they 
build rather than one-offing another solution.

The second use case is under discussion and development in the Internet2 
COmanage working group, among other places. Why don't you ask them 
what's cooking?

Tom

Chris Hyzer wrote:
> Hey,
>
>  
>
> How do people manage subjects that are distributed?
>
>  
>
> e.g. our engineering school wants to add subjects to grouper for 
> accounts to machines, which aren’t necessarily people.  Either our 
> grouper central system needs to get a JDBC or JNDI or something else 
> connection to their list of subjects, or we could add something to 
> grouper to allow delegated subject management (stored in the registry).
>
>  
>
> I think it could be as simple as a new subject source called 
> “grouperSubjects” or something, and then if you can create in a stem, 
> you can create subjects in that stem, with the stem name as part of the 
> subjectId (just to keep things separated more than just a source).
>
>  
>
> So they could add these subjects (e.g. via web service or grouperClient):
>
>  
>
> penn:seas:subjects:logins:root
>
> penn:seas:subjects:logins:sys
>
> penn:seas:subjects:logins:backup
>
> etc
>
>  
>
> And when someone was searching for subjects, or just looking up by id, 
> there wouldnt likely be conflicts…
>
>  
>
> We could just have a table in grouper:
>
>  
>
> grouper_subjects
>
> uuid, stem_id, subject_extension, creator_id, last_edited
>
>  
>
> Then the subject source would read from that (and concatenate the stem 
> name based on the stem_id with the subject_extension).  E.g. the subject 
> extension is “root”, and the stem_id is “dsdf-sfd-dsf-“ which points to 
> the stem  -   penn:seas:subjects:logins, and the subject source would be 
> grouperSubjects, and the subject_id is penn:seas:subjects:logins:root. 
>  The web services could have subject search which can filter by stem.
>
>  
>
> This would be for 1.5 or greater.  Obviously there are a lot of 
> different ways to do this, each with pros and cons…
>
> Has anyone run into this?
>
>  
>
> Thoughts?
>
> I opened a jira for it.
>
>  
>
> https://bugs.internet2.edu/jira/browse/GRP-192
>
>  
>
> Regards,
>
> Chris
>
>  
>
> Ps. Another use case could be subjects in other institutions… e.g. if 
> using federated authentication, you might have that subject in a local 
> group, even though the subject is not in your institutions idm…  this 
> might help add provide a place to put those types of subjects…  so       
> anotherSchool/jsmith, could be stored in this subject:  
> penn:external:subjects:anotherSchool/jsmith
>
> Or something…
>
>