Grouper Users - Open Discussion List

[Dave Donnelly <>]

Bert,

I can address some of your Signet-related questions:

-Is it true that signet relies 100% on groups/grouper to automatically 
grant people privileges?
No. Signet grants privileges to Subjects. A Subject could be an 
individual, a group, an
application, or anything else. Both Signet and Grouper use what is 
called the "Subject API"
to define sources (note plural) of Subject information. The Subject API 
is configurable so
that whatever Subject Source (whether a database, LDAP, flat file, etc.) 
the Subject is
brought into Signet or Grouper in a consistent manner.
There is no "automatic" granting of privileges. If you define a group 
within Grouper it
has no privileges until you assign one or more within Signet.

-Can signet work from native-ldap groups, or does it only integrate with 
grouper groups?
Using the Subject API it would be possible for Signet to work directly 
with LDAP groups.
You could have additional Subject adapters to work directly with Grouper 
and any other
sources simultaneously.

--Dave Donnelly



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
>
> 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?
>
> 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?
>
>
> 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
>
>
> Thanks yet again,
>   Bert