Grouper Developers Forum

["McDermott, Michael" <>]

On Fri, Oct 28, 2011 at 3:08 AM, RL 'Bob' Morgan <> wrote:

1. You have to be the grouper admin to add a jdbc source, if you are a lowly department programmer, and you want to add some entities, then you will have to ask your central grouper admin, and more than likely, it will either be painful to do this, or they will say no.  Or you can create groups to represent entities which can be confusing.

I'm trying to understand this scenario.  The Grouper uber-admin has a policy against adding the subjects the dept-admin wants, but because of the Grouper-entities feature the dept-admin is able to circumvent that policy?  Would not the Grouper uber-admin also have control over whether the Grouper-entities feature can be used by the dept-admin?

Or is it that Grouper deployers find the implementation of subject sources so difficult that they can't satisfy dept-admin needs even though they want to?  So the Grouper-entities feature is an easier/better way of managing Grouper subjects?

I can say from the vantage of a deployer type, if a department asked me to add a new subject source, I would probably say no unless I knew for darn sure that subject source could be trusted.

2. With a jdbc source, there is no security.  Other people who don't care about your entities can look them up and see them

If deployers care about access control for sources, shouldn't sources, y'know, support access control?  If a subject source is, for example, an LDAP directory, that certainly can do access control.

Generally speaking, it is not uncommon to grant bulk access to the application, Grouper, which then has vast privileges so it can service numerous groups.  Once you give Grouper "access", it has access, regardless of whether or not that data source should be used by ther rest of grouper.  

To solve this use case Grouper needs:

1) a facility for centrally managing which groups are tied to which data sources (it may already have this, we've not looked here into it though)  accompanied by a way for a central administrator to easily manage this facility or 

2) the facility to pass on information to the datastore to make its own decisions on what to return.  I'm pretty sure JDBC does not have a general facility to say "let me in a entity J and run query x as entity K instead." I know less about LDAP/JNDI connectors, but would be (happily) surprised here as well.  ORr

3) Scoped datasources that are managed by folks at the end of the "network."  I think this is more or less what the team is proposing.  This seems to me to be the proposal that the Groper team is trying to run down.  From a distance Jim's performance question is the one that interests me.  From a high level, tying into the UI discussion and Chris's fork/join or an Actor point, it seems an interface that accepted server push (ajax/comet or whatever) could quickly return the primary search results and then push the secondary search results as they are returned.  The client would get a response and data quickly, and then it could be supplemented as soon as possible. 

 - RL "Bob"

-- 
Michael J. McDermott
Lead Developer, Identity and Access Management
Brown University