Subject: Grouper Developers Forum
- From: Tom Barton <>
- To: Joy Veronneau <>
- Subject: Re: [grouper-dev] Idea for Source Adaptor
- Date: Tue, 19 Dec 2006 12:35:33 -0600
Is it sufficient for the grouper UI to enforce these security requirements, or are other API clients also of potential concern? It might be easier to incorporate these requirements into the UI. The API security model doesn't include a notion of differential privilege over viewing or referring to subjects - that's probably a more substantial change to contemplate.
Joy Veronneau wrote:
I'm writing with an idea for a feature for the Source Adaptor.
We'd like to be able to configure a source for the Source Adapter so that it is only visible to people who are members of a group. People who are not members of the special source view group would never see the source listed in the search screen, and subjects from that source would never appear in any of their search results. However, the subjects would appear in lists of group members that are publicly viewable.
Here are our two examples:
NetID admin client- This is the client used to generate new NetIDs. Only about 30 people can run it, and they are given special Kerberos principals to authorize them. So my NetID admin client principal might be jv11.admin and I would be a member of the NetID admin permit/group. Only two people can add/delete people from the NetID admin permit/group, and only these two people need to know about these special principals. The NetID admin principals are going to be in a new branch of our directory when we migrate to Grouper and thus they will be configured as a separate source for the source adaptor, but it would be nice if only two people could ever see if they exist. So we would create a group like "NetIDadminClientManagers" and put these two people in it.
Directory Administrators- we currently have our ACIs administered in the directory via LDAP groups. So for example, we have bind dns for people who are allowed to read/write anything in the directory, and they are members of something like the cupeoplemanagers group. We could manage all this via Grouper (I think) but we don't want anyone but 2 or 3 people to see what these bind dns look like, and we don't want them added to random groups. So we would create group called something like "DirectoryACIManagers" and put these 2 or 3 people in it, and only they would see the "directory administrators" source and subjects.
For background, we have these other sources planned for Grouper:
- our directory of NetIDs
- our directory of GuestIDs
- our directory of ServiceIDs (Kerberos principals and keytabs for applications)
- Idea for Source Adaptor, Joy Veronneau, 12/19/2006
Archive powered by MHonArc 2.6.16.