Grouper Developers Forum

[Chris Hyzer <>]

This is an old thread (ability for people with CREATE in a folder to create 
subjects in that folder), but something that is on my long-term feature list 
to discuss again.  Just wanted to register that on the paccman call today, 
there was talk about assigning privileges to IP ranges (e.g. for a library).  
Granted that is not high on the priority list for privilege management with 
grouper, but I was thinking that if a library admin could have a subject 
space to create ip addresses, they could assign privileges to that subject 
(which represents an IP range), and the decision point would need to be wired 
(e.g. with hook) to do some IP math.

To assign something to a new IP range, the library admin could make a subject:

school:library:subjects:ipRanges:123.45.0.0/16

Then could assign a privilege to that subject.  The decision point would get 
a call:

Does subject school:library:subjects:ipRanges:123.45.1.2/32 have edit 
privilege on school:library:permissions:wiki:schools:engineering?

The decision point would need a hook which would basically need to not 
resolve school:library:subjects:ipRanges:123.45.1.2/32 as a subject, since it 
most likely wont be there.  It would need to do something like, cycle through 
all subjects who have this privilege, and see if the requested subject is in 
one of those ipranges...

Anyways, just wanted to get this idea documented in case we ever discuss this 
feature of subjects in the grouper namespace... :)

Thanks,
Chris

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