Grouper Users - Open Discussion List

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

--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
> grants
> -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
> group
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
> proceed..
>
> Here is a sketch of our minimal expectations of automatic group
> maintenance:
> (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- 
> like"
> rdbms.
>         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,  
> RedHat,
> etc
>
>   - 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
> reevaluations
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,
>    Bert



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