Grouper Developers Forum

["GW Brown, Information Systems and Computing" <>]

Currently the ui searches subjects using DoSearchSubjectsAction

                if("all".equals(sourceId)) {
                        results=SubjectFinder.findAll(searchTerm);
                }else{
                        Source source = sm.getSource(sourceId);
                        results = source.search(searchTerm);
                }

SubjectFinder iterates over all sources and combines the result sets.

The list of sources presented for searching against is controlled by 
PrepareSubjectSearchFormAction:

        SourceManager.getInstance().getSources();

We could straightforwardly have a default 'getSearchSources' interface 
implementation which returns all sources, but which can be re-implemented 
to suit local rules. We could pass the current GrouperSession which would 
give access to the authenticated subject and allow group tests to filter 
the sources returned.

Gary



--On 19 December 2006 12:35 -0600 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



----------------------
GW Brown, Information Systems and Computing