Grouper Developers Forum

[Chris Hyzer <>]

Let me respond to a couple of points, then expand on why this exists:

 

Ø  I think allowing users to implement their own suject databases opens a whole new can of worms.

 

If the namespaces don’t overlap, then its as many worms as allowing users to create their own groups.  They do their own thing in their namespace and who cares?  It doesn’t affect anyone else.  The worst they can do is confuse themselves

 

Ø  Is each department going to have its own source of students?

 

Of course not, I added this to the wiki: “Entities are not intended to be used to represent people that are already represented or could easily be represented in another source.”

 

 

Ø  > I kind of think we should do fork/join for each source, and not single threaded... :)

Ø  With 2.0 I can do the search and sort on the member table alone.

 

Multi-threaded and search/sort are different things I think

 

Ø  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? 

 

No, its more that there isn’t a facility at a lot of institutions where dept-admins can self-serv add their own subjects.  And consistent WS/UI is a plus.

 

Ø  Would not the Grouper uber-admin also have control over whether the Grouper-entities feature can be used by the dept-admin?

 

Since they are in the dept-admin’s namespace, the control is delegated to the dept-admin by delegating the namespace

 

Ø  If a subject source is, for example, an LDAP directory, that certainly can do access control.

 

I don’t think an LDAP subject source has access control since Grouper accesses the LDAP from one admin account, not as the user.  (whoops, I see MichaelM responded already)

 

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

 

Right, and it’s a more work to do than nothing if this enhancement exists.  One issue with Grouper is if there are things that aren’t ready to go (e.g. use Grouper, but you have to figure out how to make your own subject source and get the central admin to integrate it), then people are more likely not to use Grouper

 

Ø  A simple way to do that is to use the Folder's pathname as the SourceId for each Subject in that Folder. So, to solve the problem of managing automatons' access to Grouper data, we're planning to enhance Grouper to be able to be the provider of any number of Subject Sources

 

This might be where the worry about performance arose, it is not actually multiple sources, it is one source, just like the group source.  So there is negligible performance impact in this enhancement.  Adding a bunch of sources for each dept-admin would definitely make things slower J

 

The use case is:

 

I am a central admin or dept admin, and I want to control access to my database.  The users of the database are schemas which are not in any subject source and that I don’t want other grouper users to be concerned about.  I want to assign permissions to these schemas.  Right now I would make a folder, and create a group to represent each schema, and assign permissions to the group, and the app does the conversion as well.  If I assign members to the group, it has no effect.  This enhancement is essentially to provide an object in the namespace which is like a group with no members.  This makes things easy to admin since if the application uses WS to assign permissions, they use the same WS stack (Grouper) to create the entity if it is not there, instead of inserting into some JDBC somewhere.  Or if the access is granted with a UI, the admin would create the entity with the Grouper UI instead of using Toad or having to make their own UI.

 

I know it might seem controversial, but I think it is not…

 

Thanks,

Chris

 

Ps. We can talk about provisioning later on… right now this is intended to be used with Grouper UI/WS… J

 

 

From: [mailto:] On Behalf Of McDermott, Michael
Sent: Friday, October 28, 2011 6:47 AM
To: RL 'Bob' Morgan
Cc: Grouper Dev
Subject: Re: [grouper-dev] Grouper-provided Entities

 

 

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