Grouper Users - Open Discussion List

[Chris Hyzer <>]

Well, Im interested in the first use case at the moment, so lets focus on 
that one.

The shortcomings of the subject API with grouper are:

1. There is no delegation management.  How can I say that someone in the 
engineering school can manage a specific source, or a specific part of a 
source (answer is custom source/rules)

2. If I make changes to the subject API sources.xml, I need to edit a prod 
config files (in loader, UI, WS, ldappc), do a lot of testing, restart my 
apps, perhaps open network connections to other people's ldaps/rdbms's 
through firewalls, get DB/LDAP credentials, etc

3. It doesn't scale.  If I give everyone a custom source who wants it, and 
there is a search by subjectId, then it will hit X db's to do X searches????  
 We need one generic namespaced source for generic one-off purposes

4. Its another barrier for a quickstart.  Granted we have the subject and 
subjectattribute tables (which we might not need anymore :) ).  These tables 
are not really supported or recommended to be used, but we do have GSH calls 
for them and they arrive in the sources.example.xml

I agree that grouper is for managing groups, and that in general it is 
convenient and a good design to hold subjects externally (e.g. IdM's), but 
for one-offs, its hard to manage groups if one cant get a quick 
representation of a subject...  I think this is common for applications in 
general.  Try to get the data from outside (perhaps of a calendar application 
uses an external ldap), but have the ability to put inside if the user wants 
so they can do their work.

If I put it outside then I have to make an external custom data layer, web 
service, another client, some way to manage namespaces, etc... :)  To put it 
inside, is one table, some web service calls, grouper client call, done.

Maybe it could be something disabled by default, and if people want to enable 
it they can?

Can we discuss at a call some time (no hurry)?

Thanks,
Chris


> -----Original Message-----
> From: Tom Barton 
> [mailto:]
> Sent: Tuesday, December 09, 2008 11:07 AM
> To: Chris Hyzer
> Cc: 
> 
> Subject: Re: [grouper-users] delegated subject source
>
> 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...
> >
> >
> >