Signet does not "peer into" a Subject just because it
happens to be a Group. Signet does not assign privileges
to an individual because he/she happens to be a member
of a group. The privilege is assigned to the Group (as a
single Subject).
This explanation does help in that it draws a strong line. However, we seem to be looking for something different -- either against the philosophy underlying Signet or something in the future but not identified by the roadmap as far as I can tell.
Groups or roles are said to have privileges, but ultimately that is a way to confer those privileges to all members as individuals.
In other words, at some point, all privileges boil down to people being authorized to do things. Groups, attributes, filters, overrides, etc are all intermediate steps to authorize people. To steal from threads I've lurked, mapping all entitlements to people might be called privilege flattening.
The audit, diagnostic, notification, precedence, life-cycle, prerequisite-checking, user-interface, and operational benefits of awareness of flattened privileges seem significant. You have clearly said that Signet does not do this flattening.
Where does privilege flattening happen today in a grouper/signet implementation? Is the answer a question of roadmap or a question about philosophy? Never? [each application checks groups] Virtual Directory? [dynamically adding group's privs to user's privs]
Signet provisioning connector? [resolves groups at provisioning time Grouper PC? [copies privileges of group into objects as they come and go from groups] Something else?
With ever-increasing thanks, Bert
On Mar 3, 2008, at 7:05 PM, Dave Donnelly wrote: As far as Signet is concerned a Subject-is-a-Subject.
Signet does not "peer into" a Subject just because it
happens to be a Group. Signet does not assign privileges
to an individual because he/she happens to be a member
of a group. The privilege is assigned to the Group (as a
single Subject).
Managing memberships of groups is done with Grouper whereas
Signet only manages the privileges of Subjects.
Does this help?
Dave
Bert Bee-Lindgren wrote:
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
|
