Skip to Content.
Sympa Menu

grouper-users - delegated subject source

Subject: Grouper Users - Open Discussion List

List archive

delegated subject source


Chronological Thread 
  • From: Chris Hyzer <>
  • To: "" <>
  • Subject: delegated subject source
  • Date: Sun, 7 Dec 2008 15:42:58 -0500
  • Accept-language: en-US
  • Acceptlanguage: en-US

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…

 




Archive powered by MHonArc 2.6.16.

Top of Page