MACE-Dirs's Approach to Support of Authorization & Messaging
by Core Middleware
Discussion Starter
Abstract: This doc provides a first crack at the definition of the problem space to be addressed by MACE-Dir in their work on "groups & attributes" over the next several months.The determination of best practises in use of groups in core middleware (especially ldap accessible directories) should be informed by the nature of the types of applications and services to be facilitated by those practises. These include (at least, and prominently) facilitation of authorization in applications and facilitation of group messaging applications. There is an expectation that, as with identifiers and authentication, enterprise core middleware can also be used to improve cost/benefit and security of the set of applications it supports with a thoughtful design for the provisioning of authorization and messaging information to applications.
I'll quite sketchily cover some ground relating to:
1. Provisioning Directories for Authorization
Let's start with a bit of reduction. An application needing to make an access control decision may have the pertinent access control policy (ie, business logic) embedded within it, or it may be that it requires a thumbs up or down indication from core middleware, with the implication that the business logic supporting that access control policy resides elsewhere (probably in the middleware). In the former case, the application likely needs to evaluate the truth of certain propositions pertaining to the authenticated object whose requested action is being subjected to the access control policy. Such propositions might take any of the following forms:
The point here is that groups aren't the only game in town when it comes to authorization. Mace-Dir should also concern itself with how best to provide a more general attribute service in support of authorization. Reality contains off the shelf applications that require it.
2. Maintenance of Group Membership Attributes
First, let's consider what attributes we mean here. These follow the different types of groups we might be maintaining:
static: a group object is instantiated with an attribute listing
the (person or other) objects which are members.
dynamic: membership is defined by evaluating an ldap search
filter. A group object may, but need not, exist.
forward reference: a special case of dynamic representation
in which an object's group memberships are listed as the values of an attribute
designated for that purpose.
spatial: another special case of dynamic representation in which
group membership is inferred from location in the DIT. The dn "coordinates"
of objects determine membership, which is dynamic because a trival search
filter selects all children of a given node.
A common static group representation is groupOfUniqueNames. Its uniqueMember attribute is a dn-valued membership list that must be maintained. The defining attribute(s) for a dynamic group may exist for independent reasons and so pose no new maintenance burden, or not. Especially so in the case of forward references, which are "dual" to static groups. There is a similar maintenance burden, but because of DSA ACLs the different locations of the group membership information for static and forward referenced groups have implications both for how it can be maintained and for how it can be accessed.
Types of groups must also be matched with the types of processes required to maintain their memberships, with the types of access that applications may be prepared to use, and in some cases with the impact on DSA performance or configuration. The updater of a group's membership must be permitted appropriate modification rights by the DSA's ACLs, which probably means that it would be inappropriate to represent a group of people dynamically if the updater is not priviledged. So for example, an "ad hoc" group for which the maintenance is delegated to a person not having other special rights within the directory really must be represented statically - an ACL can permit them to modify the membership attribute of just that specific group object. The alternative would require ACL(s) that permit them to update certain attributes for all people objects, which might also permit them to change more than just the membership information for that one group.
These days off the shelf applications, if they use ldap at all, may do so in a rather limited way. It may be, for example, that an app can be configured to use either a single ldap search filter scoped to the authenticated object, or a single static group membership, to implement an access control policy (such as a certain apache ldap module). If the access control policy to be achieved is sufficiently complex, ie, referencing multiple group memberships, or a combination of group memberships and person attributes, then the repesentation in the directory of that authorization information must be redesigned to meet the limited access capability. So, middleware must maintain either a special static group based on the access control policy or appropriate attributes in person objects.
If it should occur that one object can belong to many groups, then exclusive static representation of groups might not be optimal. A list of all of their memberships might exceed the search limit set for the DSA, for example. On the other hand, there is the potential for some types of dynamic groups to require serious processing by the DSA in order to perform the defining ldap search, if the entire membership of the group must be computed. Also, it may be that some DSA products have limitations on the maximum size of a static group (eg, Active Directory cannot store a static group with more than 5000 members).
Finally, there's the matter of "group math". Perhaps, because of operational realities, the group of real value to an application is some combination of other groups that are directly maintained. For example, consider an automatically maintained group of all faculty as determined by the HR system. The Research Office might wish to use that for certain mailings, except that they need a few non-faculty to also receive those mailings, and they also desire to honor the wishes of a few faculty members who appear to have nothing better to do than to complain about being on their email list. The Research Office might be given two ad hoc static groups for which they maintain the memberships, one for additions to the administratively defined group, the other for omissions, but how should these three groups be resolved into a mailling list without recourse to providing the Research Office with a custom program?
3. Provisioning of Groups for Messaging
TBD
4. eduPersonAffiliation Values
Let's start this off with a proposition: a convention's scope is the community that defines it. A corollary is that the larger the community, the smaller the set of conventions that can hold for it. This is what is hard, no - impossible, about standardizing global values for ePAffil. On the other hand, there appears to arise out of some communities a desire to use something like ePAffil for some purpose(s) meaningful to that community. So, one approach is to use a hierarchical syntax for ePAffil values that enables delegation to each interested, self-declared, community of the authority to define values specific to their purposes. For example, OIDs might be used since the central OID registration system assures that each initial OID arc is globally unique. They're great delegatable values. Others systems might work just as well provided that they assign to each self-selecting community a unique value prefix, and two or more such systems might even coexist as acceptable ePAffil value syntaxes provided that their representations are disjoint.
Isn't all that's really needed for an ePAffil application the ability to do equality matching for one or more of a given community-derived set of values?
5. Representation of Correlations
TBD
6. Author Information
Tom Barton
Information Systems
The University of Memphis
tbarton@memphis.edu