Grouper Users - Open Discussion List

[Tom Barton <>]

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
> 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.

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!

Tom