Skip to Content.
Sympa Menu

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

Subject: Grouper Users - Open Discussion List

List archive

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


Chronological Thread 
  • From: Bert Bee-Lindgren <>
  • To: Dave Donnelly <>
  • Cc: ,
  • Subject: Re: [signet-users] Automating group memberships (and signet privileges)
  • Date: Mon, 3 Mar 2008 16:51:46 -0500

I think either my mind or my words (or both) were fuzzy on "automatic."

My questions were phrased assuming that Signet assignments to groups would do something to incoming and outgoing members as the group's native membership changed. "Something" would include internal documentation of who-had-what-privileges as well as provisioning via LDAP or Application PC.

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.


Understood. Then what happens to the members of the group at assignment-time as well as the incoming- and outgoing-members as time passes?

For example, if I have a Grouper group of all our students and that group is assigned a file-server privilege in Signet, can Signet keep an authorizing eduPersonEntitlement value correct in the members' LDAP objects?

Or, on the other hand, does Signet never peer-into the group? (FWIW, I can't find a way to peer into a Subject in draft 0.2 of the Subject API.
http://middleware.internet2.edu/signet/docs/subject-api-spec-0.1-draft-02.html ).


Sincerely,
Bert

On Mar 3, 2008, at 1:59 PM, Dave Donnelly wrote:

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






Archive powered by MHonArc 2.6.16.

Top of Page