Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] delegated subject source

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] delegated subject source

Chronological Thread 
  • From: Tom Barton <>
  • To: Chris Hyzer <>
  • Cc: "" <>
  • Subject: Re: [grouper-users] delegated subject source
  • Date: Tue, 09 Dec 2008 10:06:37 -0600


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?


Chris Hyzer wrote:

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





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:


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?


I opened a jira for it.



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…

Archive powered by MHonArc 2.6.16.

Top of Page