Institutions contemplating projects that require numerous groups to be managed within their enterprise directory services often confront a variety of operational issues to do with the management of, representation of, and access to group information. The creation of a tool to facilitate these operational tasks has been identified as a high priority activity by the Internet2 MACE-Dir working group. Named SAGE, this document is the initial step towards specifying the functional capabilities that it should embody.
This document is a product of the Internet2 Middleware Initiative, and the Middleware Architecture Committee for Education (MACE), published under the auspices of the National Science Foundation Middleware Initiative (NMI). Internet2 is a member of the Enterprise and Desktop and Integration Technologies (EDIT) Consortium, participating in the NMI.
This is one of a growing set of documents created by MACE , detailing various issues surrounding the planning, deployment, configuration, maintenance, and security of enterprise directories.
For additional information and related topics and resources see the following sites:
| Internet2 Middleware Initiative: |
http://middleware.internet2.edu/ |
| MACE: |
http://middleware.internet2.edu/MACE/ |
| EDIT: |
http://www.nmi-edit.org/ |
| NMI: |
http://www.nsf-middleware.org/ |
Table of Contents
1. Introduction
2. Scenarios
2.1 Typical enterprise groups implementation
2.2 Privacy and visibility
2.3 Group math
2.4 Role based access control
2.5 Web service
2.6 Code library
2.7 Integration with legacy systems
3. SAGE integration model
4. References
5. Acknowledgements
6. Author information
Many institutions have adopted a core middleware infrastructure that provides users with a common identity that can be used to access numerous applications integrated with this infrastructure. Compared to previously emplaced siloed IT architectures, in which separate user management processes and technologies are associated with each application, this approach simplifies access to services from the user's perspective and minimizes the operational and administrative overhead of providing that access. It is a framework in which the marginal cost to add new applications or new classes of users is comparatively low, in part because a common set of tools, technologies, and procedures are used to manage identities and authentication across applications and user communities. See [7] for a discussion of the business values of this type of architecture and [5] for a more technical overview of this architecture. The technical and policy related processes needed to build this type of architecture are compiled in [8].
In addition to a common identifier, the identity management capabilities of an integrated core middleware infrastructure allow attributes about people to be associated with them and made available to applications using common technologies. This data can be used by applications to evaluate access control expressions or otherwise automatically entitle users to whatever they are permitted to access. However, this approach usually does not provide a complete solution to the problem of provisioning authorization or entitlement across applications and user communities. A variety of techniques and processes associated with each application are used to make up the difference. Hence, there is an opportunity to simplify this aspect of current practice in IT architecture in a manner analogous to how integrated core middleware simplifies management of identity and authentication.
Group memberships can be used by many applications as further data to feed their access control and entitlement logic. But the current model of integrated core middleware lacks a common means by which to manage groups across applications and user communities. This is the niche that SAGE is intended to fill.
A variety of operational issues to do with the management of, representation of, and access to group information must be confronted. A multiplicity of information sources, processes, and persons need to be coordinated to produce a unified outcome. The group information itself may need to be represented in multiple ways or in multiple locations to enable easy access by client applications. Consistency among multiple representations must be maintained. Regulatory, institutional, and operational policies bearing on the security model for and on the life cycle of group information need to be followed. As groups deployments mature, further operational issues become apparent. A balance must be struck between the convenience and efficiency of using subgroups to manage access to services versus the scarcity of applications that can distinguish between direct and indirect group membership. Often the group that would be just right for some purpose isn't being maintained, but some combination of existing groups would do the job, if only there was a way to refer to it. Also, bearing in mind that if a site has N people, then there are 2**N possible groups of those people, over time more groups than people are likely to have to be managed, perhaps many more. The stale ones will need to be aged out. See [1] for a more detailed discussion of these issues.
The initial conception of SAGE, the Service for Authorized Group Editing, is that it should embody a means for managing operational issues such as these, so that institutions can use it as a starting point for supporting their groups implementations. Hence, SAGE should make it easier for institutions to extend their enterprise directory service infrastructure to serve applications requiring group information.
SAGE is envisioned in part as a mechanism for provisioning groups. For individual groups, it is a facility for creation, maintenance, and life cycle management. SAGE also provides the means to construct and manage a partial ordering of the set of groups, thereby supporting the use of subgroups, indirect membership, and role hierarchies. And SAGE provides a means of specifying groups whose memberships are set theoretic combinations of the memberships of other groups. SAGE relies on an external system that assigns and manages the identities of persons and other objects that may be designated as members of groups that SAGE manages. Thus, a prerequisite for sites to run SAGE is an established identity management system. Specification of direct membership in SAGE managed groups relies on site-specific means of referring to member objects. SAGE treats references to member objects not constructed by itself as opaquely as possible.
In section 2 several scenarios are provided which SAGE might facilitate. These are intended to further illuminate what SAGE can help a site to accomplish. They will also serve as the basis for deriving SAGE's functional requirements, which will be enumerated in a subsequent document.
Section 3 sketches how SAGE might articulate with an existing enterprise directory services architecture. This model identifies interfaces SAGE may need to present to elements of that architecture. However, over the wire protocols, message formats, message flows, detailed interface semantics, and SAGE's internal structure are not addressed in this document. These will be the focus of a subsequent stage of development of SAGE.
SAGE represents a new type of element in a core middleware architecture. There are neither prior models nor established expectations for the sort of function that it should provide. The information technology, middleware, and application architects for whom this document is written are especially encouraged to communicate their feedback on the concept of SAGE and on how this new element might complement their existing architectures to the address at the top.
It is anticipated that the art and heart of SAGE will prove to be its management of group metadata. Where and how a group is to be provisioned, security & privacy information (who can do what to which groups), relation to other groups, state of a group with respect to its life cycle and its referential integrity, and other non-membership information will form the core of the data that SAGE manages. A possibly illuminating partial truth is that SAGE is about managing a partially ordered set of group "containers" to which memberships and other information can be attached.
2.1. Typical enterprise groups implementation
Alpha University employs groups to support a variety of authorization, customization, and messaging functions in several applications. AU's key administrative systems are the authoritative source of membership information for sets of groups that are to be automatically maintained, including groups corresponding to class sections and groups associated with employees' departmental affiliations. Other groups are manually maintained by persons affiliated with departments, work teams, committees, and vertical applications because administrative systems do not contain information bearing on their memberships. Automated update processes as well as applications that mediate manual group maintenance tasks interact with SAGE to accomplish the emplacement of group information within AU's enterprise directory services.
All groups contain membership information, indications of who is permitted to maintain group information, and indications of who can view group information and who can see the group itself (cf. section 2.2). SAGE both facilitates the specification of this security information and also adheres to it in its own security model.
Some groups contain extended information specific to their functional purpose. For example, course related groups contain lists of instructors, students, teaching assistants, course developers, and course metadata such as course & program identifiers, meeting locations and times, and credit hours. SAGE is transparent to such extensions. It permits extended attributes to be identified and their values maintained.
Some applications perform their authorization, customization, or messaging functions by referring to attributes in LDAP resident static group objects. Others refer to attributes (such as isMemberOf) in LDAP resident person objects to supply information for these functions. SAGE provisions both of these representations in LDAP directories and maintains referential integrity between them.
AU operates several different directory services. Some groups appear in all of them while other groups appear only in specified ones. SAGE maintains synchrony between groups that are presented in multiple directory services.
AU operational policy entails that groups no longer in use should be identified and removed at an appropriate time. SAGE provides an aging facility that AU uses to implement this aspect of their policy.
Alpha University is subject to governmental regulations such as the Family Educational Rights and Privacy Act (FERPA), the Health Insurance Portability and Accountability Act (HIPAA), or the European Union Privacy Directive (Directive 95/46/EC). AU's local privacy policy further extends certain privileges and responsibilities both to individuals and to departments to control the dissemination of information about some of their group memberships. As a result, knowledge of who belongs to what groups needs to be constrained in some instances. Furthermore, knowledge of the existence of some groups also needs to be constrained. SAGE facilitates the association of this information with each group and also incorporates this information into its own security model. However, SAGE does not attempt to automatically update the native access control mechanisms of any repository within which it maintains group information.
Alpha U application developers and service administrators must sometimes implement access control policies that bestow specific access rights to objects belonging to a set theoretic combination of group memberships. Similarly, AU operates a messaging system that permits a recipient list to be constructed from a set theoretic combination of group memberships. Through its web services interface SAGE provides a run-time mechanism by which applications can either request if a given object belongs to a specified set theoretic combination of group memberships, or request the entire membership of a specified set theoretic combination of groups. SAGE's group creation mechanism also provides a means of defining a new group as a set theoretic combination of existing groups, thereby enabling run-time queries about the resultant set theoretic combination of group memberships to be expressed as queries pertaining to a single group. In particular, this new group can be represented in an LDAP directory service, enabling ordinary LDAP queries to resolve membership questions about the set theoretic combination of existing groups.
2.4. Role based access control
Alpha U uses its enterprise directory services to supply information to applications to enable them to evaluate access control and entitlement logic. AU has found that information in the form of attributes located in person entries or group memberships is sufficient to implement comparatively simple access control policy. For example, "require" directives implemented in apache's mod-ldap module are used to restrict access to some web content and applications. However, AU has found that the security model of more sophisticated applications, especially some of its administrative applications, is better managed with a role based access control model (RBAC) in which people are assigned to groups, roles are associated with permissions within those applications, and groups (and some people) are associated with roles. AU has followed RBAC models and practices such as those described in [2], [3], and [6].
Roles resemble groups in that they contain direct or indirect membership information. In addition, roles contain information indicating permissions, constraints, and obligations associated with each role. The set of roles has a partially ordered structure which is used to facilitate management of the RBAC system. Effective membership (i.e., direct and indirect, or in the terminology of [2], assigned and authorized) flows to junior roles, and effective permissions, obligations, and constraints flow to senior roles. AU uses SAGE's ordinary group management features to support its RBAC authorization system. The membership attribute of a role is most often a list of other groups being maintained by SAGE. Thus, the process of maintaining membership in groups is separate from the process of assigning groups to roles. This fits well with AU's circumstances since group memberships changes more rapidly than the role structure, and because memberships in groups and in roles are maintained by separate business processes.
AU has found it convenient to represent the partially ordered role hierarchy by listing senior roles as members of immediately junior ones, i.e., by making use of subgroups. With this practice SAGE's direct membership query provides the RBAC system with a role's assigned members, and SAGE's indirect (aka effective) membership query provides it with a role's authorized members.
The additional attributes holding obligations, constraints, and permissions are transparent to SAGE. However, AU leverages SAGE's API to compute direct and indirect obligations, constraints, and permissions of roles. AU treats the attributes holding each of these lists analogously to the membership attribute. It lists subordinate roles in obligations, constraints, and permissions attributes in immediately senior role objects. SAGE is then directed to consider one of these attributes to be the "membership" attribute, and to return the direct or effective membership of a role. The result is the direct or indirect obligations, constraints, and permissions of the role. Furthermore, this practice has allowed AU to view their roles as having multiple hierarchies, giving their RBAC system a degree of freedom that accommodates circumstances in which they wish, for example, to limit the inheritance of a permission to a subset of roles senior to the role it is assigned to.
AU uses a subset of its roles database to manage the association between people and host accounts they are assigned. Account objects are viewed as leafs in a partially ordered set of roles. Permissions in host operating systems are automatically synchronized from this database by a process unrelated to SAGE. In addition to host operating systems, some applications also refer to these roles in their access control expressions. SAGE supports this scenario exactly as in the preceding paragraphs.
Application development at Alpha U is committed to use of a web services approach across many of their systems (cf. section 2, "What is a Web service?", in [4] for the definition of this term as used here). Some of AU's core business systems vendors are likewise developing their products in support of a web services style architecture. Consequently, AU provides a web services style interface to its database of groups and operations upon them using SAGE's web services interface.
Application developers at Alpha U are committed to use of common libraries across many of their home-grown applications. The SAGE API is natively implemented in a code library in at least one of the following language types: C, Java, Perl.
2.7. Integration with legacy systems
Like most institutions, Alpha U has its share of legacy systems that do not employ "modern" techniques for integrating with external systems. SAGE implements a limited batch import/export interface for use with legacy systems.
Following are sketches of several ways in which SAGE might integrate with and complement an enterprise's existing identity management and directory services. These help to define the behavior needed at SAGE's external interfaces.
We'll assume that Alpha U's existing architecture has at least the following elements. Aspects of this type of architecture are described in more detail in [5].
Central Data Sources - primary sources of attributes and identifiers about people affiliated with Alpha U.
Ad Hoc Data Intake - one or more processes that mediate the intake of additional attributes and identifiers about people arising from sources distributed throughout the enterprise. Individuals or other departments are delegated authority by central IT to inject these data into AU's identity management and directory services processes.
Metadirectory - the set of processes used to collect, transform, and integrate source data to manage AU identities, and that place resultant data in one or more consumers where it can be accessed by applications. No assumption is made about the types of technologies that constitute the metadirectory. Use of this term is sometimes viewed as requiring a significant abstraction of actual practice.
Consumers - locations, such as directory servers, relational databases, and flatfiles, into which processed identity data is placed by metadirectory (and possibly other) processes. Consumers are the point at which integrated applications access infrastructure middleware services providing authentication, attributes, and groups to facilitate evaluation of access control expressions.
Integrated Applications - systems and processes providing service to end users and that rely on data housed in consumers for their task.
SAGE may interface with each of these types of architectural elements, as shown in the figure below and described in the paragraphs that follow.
SAGE integration model
Metadirectory
Much information about group membership and other group metadata
arises from attributes in central data sources. Metadirectory processes
external to SAGE must transform this source information into expressions
of group membership, metadata, or other group management information suitable
for input to SAGE. Membership information may be presented to SAGE as a
complete list or as incremental changes to membership.
Consumers
SAGE has the capability to provision groups in one or more consumer
systems, although not all groups need be provisioned - this is an aspect
of group metadata that can be set by authorized principals. SAGE can
represent a provisioned group in either a static or forward referenced
fashion (or both). A static presentation is one in which the group is
represented in the consumer by means of a mapping from group to
membership. Examples include a group table in a relational database whose
rows correspond to and identify members of the group, and a groupOfNames
or groupOfUniqueNames object in an LDAP directory in which the list of
members is contained in a multivalued attribute. A forward referenced
presentation is one in which the group is represented in the consumer by
means of a mapping from members to the group. Examples include a table in
a relational database each of whose rows correlate a member with a group
to which the member belongs, and an multivalued attribute in a person
object in an LDAP directory whose values indicate groups to which that
person object belongs. SAGE can interface with relational or LDAP
consumers over a real time connection to maintain group information housed
there. SAGE can also export a flat static representation of group
membership for batch integration with consumers, including legacy consumer
systems lacking the capability to be integrated in real time with SAGE's
group management.
Ad Hoc Data Intake
An ad hoc data intake process can communicate group management information
to SAGE arising from delegated sources authorized to do so. SAGE's internal
security may also be maintained in this fashion, i.e., the set of groups
and roles that underpin SAGE's security model may be maintained using such
a process.
Integrated applications
Integrated applications (including an
ad hoc data intake process) can access group information that has been provisioned
by SAGE into consumer systems. However, they can also interact directly
with SAGE to resolve selected group related queries if they are so authorized.
There is a fundamental consideration that bears on how SAGE might interface with an existing architecture. For SAGE to provision a group into a set of consumer systems, those consumers must at least have a coordinated style of reference to member objects sufficient to enable SAGE to determine how to write a reference to a member object in a given consumer. Thus, one instance of SAGE can provide service to at most the set of consumers operated within a common identity management system. For example, it might be possible to design SAGE so that it can provision the same group into two LDAP directories in which one uses "uid" as the relative distinguished name and another uses "cn". But this can only be possible if a one to one mapping between uid and cn can be constructed based upon a common identity management operation that populates both LDAP directories. Just how (and if) SAGE may be able to interface with an external system to aid in evaluating such identity mappings is a matter for future discussion among members of the MACE-Dir working group.
[1] "Practices in Directory Groups", Tom Barton, Internet2 MACE-Dir working group document, October 2002. http://middleware.internet2.edu/dir/groups/internet2-mace-dir-groups-best-practices-200210.htm
[2] "Proposed NIST Standard for Role-Based Access Control", David F. Ferraiolo, Ravi Sandhu, Serban Gavrila, D. Richard Kuhn, and Ramaswamy Chandramouli, ACM Transactions on Information and System Security, Vol. 4, No. 3, August 2001. http://csrc.nist.gov/rbac/rbacSTD-ACM.pdf
[3] "A Policy Framework for Management of Distributed Systems", N. Damianou, PhD Thesis, University of London, February 2002. http://www-dse.doc.ic.ac.uk/Research/policies/ponder/thesis-ncd.pdf
[4] "Web Services Architecture", W3C Working Draft, 14 November 2002. http://www.w3.org/TR/2002/WD-ws-arch-20021114/
[5] "Metadirectory Practices for Enterprise Directories in Higher Education", Brendan Bellina, editor, Internet2 MACE-Dir working group document, October 2002. http://middleware.internet2.edu/dir/internet2-mace-dir-metadirectories-practices-200210.htm
[6] "Authority Project", Lynn McRae, Stanford University, October 2002. http://www.stanford.edu/group/itss-ccs/project/authority/
[7] "Middleware Business Case", Internet2 Middleware Early Adopters Team, 26 October 2001. http://middleware.internet2.edu/earlyadopters/draft-internet2-ea-mw-business-case-00.pdf
[8] "Enterprise Directory Implementation Roadmap", Ann West, draft. http://www.nmi-edit.org/update/roadmap/directories.html
Thanks are due to the participants in the Internet2 Middleware Initiative MACE-Dir working group, who support and substantially contribute to this effort.
This work was supported in part by the NSF Middleware Initiative - NSF 02-028.
Dr. Tom Barton
Networking Services & Information Technologies
The University of Chicago
tbarton@uchicago.edu