Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Idea for Source Adaptor

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Idea for Source Adaptor

Chronological Thread 
  • From: "GW Brown, Information Systems and Computing" <>
  • To: Tom Barton <>, Joy Veronneau <>
  • Cc:
  • Subject: Re: [grouper-dev] Idea for Source Adaptor
  • Date: Tue, 19 Dec 2006 19:11:10 +0000

Currently the ui searches subjects using DoSearchSubjectsAction

if("all".equals(sourceId)) {
Source source = sm.getSource(sourceId);
results =;

SubjectFinder iterates over all sources and combines the result sets.

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


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.


--On 19 December 2006 12:35 -0600 Tom Barton

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




GW Brown, Information Systems and Computing

Archive powered by MHonArc 2.6.16.

Top of Page