Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] Automating group memberships (and signet privileges)

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] Automating group memberships (and signet privileges)

Chronological Thread 
  • From: "GW Brown, Information Systems and Computing" <>
  • To: Bert Bee-Lindgren <>, ,
  • Subject: Re: [grouper-users] Automating group memberships (and signet privileges)
  • Date: Tue, 04 Mar 2008 16:14:14 +0000

--On 03 March 2008 13:14 -0500 Bert Bee-Lindgren <> wrote:

[I'm sorry for the barrage of questions. They've been building up, and
I've finally taken the time to get them on paper. On the bright side, I
think this is the last question for today :)]

I am continually missing something, and the recent grouper dynamic- group
thread just made it worse. I'm hoping somebody here can set me straight.

My questions are:
-Is it true that signet relies 100% on groups/grouper to automatically
grant people privileges?
-Can signet work from native-ldap groups, or does it only integrate with
grouper groups?
-Does grouper have the ability to automatically authorize people (or
accounts) for membership?

Here's what I think the answers are. Please correct me:
-Yes, signet relies on groups/grouper to automatically grant people
privileges, except for prerequisites that automatically enable manual
-Grouper has no ability itself to query LDAP to automatically add/ remove
memberships from people
-An external tool is necessary to query LDAP (batched or triggered) and
use the grouper APIs to manipulate associated group memberships
-Grouper does not have a temporary-assignment ability of a subject to a
Do you mean a membership which can be given an expiry date?

There has been talk of such a feature but one has not been implemented and is not currently high on the list of priorities.

We've spent some time on our core person register: making it more open
(ldap vs custom-rdbms, ldap-change event queue, standard schemas, etc)
and more complete (finer-grained & multiple affiliations, course-
enrollments, multiple jobs, departmental data, etc). Theoretically, we
couldn't be more ready to migrate to grouper, but we're not sure how to

Here is a sketch of our minimal expectations of automatic group
(This list of automatic maintenance intentionally ignores all manners of
manual maintenance)
-Define multiple enabling rules for a group, and have peoples'
memberships change as their data change
-Use of LDAP to evaluate rules
-Rules' conditions made up of LDAP group-membership or LDAP filters

Any options exist to help get this done?
Some work has been done for exporting Grouper information to LDAP - ldappc, however, it is beyond the scope of the project to provide 'loaders' given the diversity of source systems and business logic on different campuses.

I expect most sites will write custom loaders - which are free to make logic decisions in any way you want, including by querying LDAP. The loader I use at Bristol queries source systems (RDBMS) to find appropriate members, but you could iterate over all your 'Subjects', determine the groups they ought to be in vs the groups they are actually members of, and effect the changes -obviously better if you only iterate changed subjects. You need to differentiate groups where the membership is maintained by a loader vs ad hoc groups you expect to be maintained through a UI, so you don't delete memberships by accident.

Making an assumption, let's say we adapt our internal data-to- privilege
system to be data-to-grouper-groups system:
-Why is it better to put the results into grouper instead of LDAP groups
or LDAP attributes and use a virtual directory to make groups?
It isn't necessarily better - many sites which maintain their groups in Grouper will provision the data to LDAP for applications to use. Grouper provides many ways for viewing and manipulating groups - something LDAP is not designed to do. What Grouper does allow is to manage ad hoc groups along side system managed groups and to have a consistent view of all groups. It also allows devolved management of groups.

In addition you can design some levels of indirection to work around the need to supplement groups - as I discussed in a previous response.

Do either of the following components exist in any OSS form? Would
either be useful to the community?:
- Fedora Directory Server change-notification system...
LDAP changes (DN, attributes, new values) posted to "event-queue-
We found the retro-changelog and/or persistent LDAP queries to be too
unreliable and ephemeral
Should work with any netscape-derived directory server -- Sun,

- An LDAP-based filter- and group-matching system that could update
grouper memberships, extracted and generalized from our custom policy/
authz system
Ties to that "event queue" above for change notifications & intra-day
This would need to be part of a loader designed to run as a daemon and able to listen to events - so again beyond the scope of the core project. We will be working on the opposite i.e. having the ability to propagate events occurring within Grouper externally.

Thanks yet again,

GW Brown, Information Systems and Computing

Archive powered by MHonArc 2.6.16.

Top of Page