Grouper Developers Forum

[Joy Veronneau <>]

Hi All,

We discussed this a little bit - we think for this feature to be most  
useful it should go in the API.  I'm not sure it's a high priority  
though.  We can get around this for now by exposing the netid admin  
client principal source, and by not managing our directory  
administrators group from within Grouper.

Joy


On Dec 19, 2006, at 1:35 PM, Tom Barton wrote:

> 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.
>
> Tom
>
> Joy Veronneau wrote:
> > Hi,
> > 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)
> > Comments/Questions?
> > Thanks-
> > Joy