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 11:58:01 -0600

Chris Hyzer wrote:
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

The need for delegation and the incidence of edits to prod config files are both aspects of scale. How many distinct IdM operations are there on a campus that remain independent from each other? I doubt that, whatever the number, it's large enough to cause a scaling issue. The high water mark I'm personally familiar with is 4 IdM operations on one campus.

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

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.

This is your best point, IMO, and a winner for many applications. But what good does it do anyone to get a Subject created locally in grouper only? It only matters if that Subject also appears somewhere external to grouper.

I'm reticent to add another place to which identity info must be synchronized rather than referred to.

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

You bet!


Archive powered by MHonArc 2.6.16.

Top of Page