draft-barton-grouper-roadmap-03.html
Tom Barton, editor
The
Comments to: tbarton@uchicago.edu
Draft for discussion by the mace-dir-groups project group.
Grouper Roadmap
This document identifies elements of the Group Tools Architecture [1] to be developed as part of the initial release of Grouper and lays out the high level steps culminating in that first release. The components to be incorporated into Grouper, feature support, potentially contributed elements, and points of articulation with other activities are listed below and developed in more detail in sections 2 & 3.
During the MACE-Dir-Groups conference call of
· The Stream Loader should be pushed into a release sometime after v1. Since the only uses for the Rules Database and the Rules API in [1] are to support Stream Loader operation, these may also be slated for a release after v1.
· Change log based provisioning should also be delayed until after v1.
· It is desirable to incorporate change log based provisioning into an earlier release than the Stream Loader, if they can’t be reincorporated simultaneously.
· Support for compound groups should remain in v1.
· The Groups Registry schema should continue to support multiple membership fields and extensibility of group types; however, the initial specification of the Groups API need not expose those underlying capabilities.
The working group will solicit contributed elements of the Group Tools Architecture. These include:
· An LDAP provisioning connector.
· An Active Directory provisioning connector.
· An implementation of the member lookup and presentation interface that uses an LDAP directory (this interface is discussed in section 2).
Thus, Grouper proper will include the Groups Registry, Groups API, a Groups Manager UI, and several simple programs using the API to batch load and export groups. The latter might be used by a site as a starting point for building their own automated loading and provisioning applications.
Finally, we should write implementation, API usage, and UI usage documentation.
The following sections discuss in further detail the functionality to be supported in Grouper v1 and list the steps we’ll take to produce an initial Grouper release that conforms to the recommendations listed above.
Grouper v1 development will proceed in three phases.
· Phase 1 contains basic management and export functionality such as creation, deletion, and listing of membership.
· Phase 2 adds support for compound groups and fully supports articulation with the Stanford Authority System.
· Phase 3 adds support for aging and other periodic tasks.
This arrangement will allow the working group to continue work on specifications for the later phases in parallel with coding and testing of earlier phases of functionality.
There are three functional areas that should have abstracted interfaces to enable alternate capabilities to plug-in to Grouper. These are:
· Management of authorization internal to Grouper.
· Lookup and presentation of memberID’s, i.e., the opaque identifiers of external objects that are members of groups.
· Determination of “last activity time” of a group.
Grouper will include an implementation of the authorization interface that relies on groups within the Groups Registry to express who the Groups API will permit what access to the Groups Registry and to the API.
Grouper will include an implementation of a lookup and presentation interface that refers to a “member” table in the Groups Registry. This table will translate memberIDs into presentationIDs, enabling the UI to search for and present member identifiers in terms that may be more meaningful to humans than memberIDs. Grouper will also include a program to perform batch maintenance of this table from an external source, and the API will include a corresponding lookup function. A site may wish to implement the member lookup and presentation interface in a manner that refers instead to their LDAP directory, for example.
Grouper will also include an implementation of the group inactivity interface that is based on last time at which a management function was performed, i.e., the only type of internal activity that Grouper can use to trigger aging. Sites may wish to supply an alternate implementation of this interface that provides a different inactivity signal to drive Grouper’s group aging capability. For example, some sites might know last access time in a consumer for many groups, and wish to base aging on that criterion instead.
The Groups API will be coded in java and the three abstracted functional interfaces described above (internal authorization, person lookup, and group inactivity trigger) will be expressed as java interfaces. Run-time interfaces with processes external to the Groups API will be mediated by the JVM in typical java fashion. So, external processes and plug-ins must either be coded in java or in any language that can instantiate java objects and implement java interfaces. Addition of a web services style of interface has been deferred at least until requirements should surface that can’t be met within the java framework.
All SQL statements supporting the creation of the Groups Registry and the interface between the API and the Registry will be located in flat files that are read by the API at initialization. Thus, sites can easily identify Grouper’s reliance on SQL and modify its SQL expressions as needed to adapt Grouper to local database technology. We intend to constrain use of SQL to basic functions so as to reduce or eliminate the need to actually modify Grouper’s SQL statements.
Milestones are numbered by phase and step within phase.
Finalize all aspects of the schema supporting basic group management, including support for subgroups, multiple membership fields, and extensibility of group types. The schema should also include a “members” table whose two essential columns are “memberID” and “presentationID”. Also finalize the specification of the “base” group type.
The API primarily supports management of groups in and export of groups from the Groups Registry. It is not intended to embody a versatile query capability. Extensive query activities should be directed against a consumer provisioned with group information. The provisioning activity is supported by export capabilities in the Groups API.
Management functions support creation, deletion, and modifying group membership and group metadata. Export functions support listing of group data and immediate and effective membership. In addition, the abstracted authorization interface should be specified and implemented as discussed above, as should support for maintaining and searching the member table. The functional specification of Grouper’s internal authorization must be completed before the specification of the authorization interface can be finalized.
It is intended that a flattened representation of group membership be maintained at all times. This means that as a memberID is added to or removed from the membership of a group, all dependent effective memberships of that memberID are also determined and the membership table is modified accordingly. Support for subgroups is included in phase 1, so it will be necessary to determine the immediate and effective memberships of a given memberID. The working group should discuss whether this algorithm should be exposed in the API. It would represent a significant query capability. It could also be justified as a reporting capability aimed at determining the changes to the Groups Registry (and potentially the changes to consumers in which groups are provisioned) needed to effect a change of memberID assigned to a given real world subject.
Finalize logging requirements and functional specification for phase 1 capabilities.
Supports at least the first phase, basic functionality, including logging.
These should include programs to create and delete groups, to list group metadata and immediate memberships, and to maintain the members table. These are used to exercise and test the API, and may serve as examples of how to use the API that sites can use to build their own automated loading and provisioning applications.
1.6. Initial UI development
Implements first phase functionality and is first stab at UI design. The UI uses the API for all access to the Groups Registry. It should also abstract an interface for member lookup and presentation. The implementation of this interface will use the API’s member lookup and presentation capability.
1.7. Feedback from focus group
Demo the UI and API capabilities to a selected small set of sites planning to implement Grouper, and get their feedback for incorporation into the design. Location (virtual or physical) and timing TBD!
And finalize corresponding elements of the Groups Registry schema.
The Authority System and Grouper are expected to articulate in two ways. Grouper will house groups to which authority is to be assigned, and compound groups will be used to further refine the ability to manage assignment of authority or permissions to aggregates. To meet the first requirement a means of provisioning the Authority Registry with appropriate information about aggregates must be developed. Alternatively, if the Authority Registry is not to house information about aggregates, a means of supporting a real-time interface enabling the Authority System to access information about aggregates must be developed. The Authority System’s UI and export subsystem each require access to aggregate information.
To meet the second requirement, we will need to resolve whether a user of the Authority System UI will use that UI to manage compounding of aggregates, or if the user will be obliged to use a separate Grouper UI to handle that aspect of their work. The former would probably require considerably more sophistication, something like an abstracted interface for managing compound groups that can be included in both the Grouper and Authority System UIs.
Support for maintaining flattened membership representation of compound groups and for any real-time or export requirements not present in the phase 1 API specification needed for articulation with the Stanford Authority System.
Finalize logging requirements and functional specification for phase 2 capabilities.
Adds support for compound groups and any additional requirements needed to articulate with the Stanford Authority System.
Demo the UI and API capabilities to a selected small set of sites planning to implement Grouper, and get their feedback for incorporation into the design.
Support aging of groups and of group memberships. The API will include an abstracted interface for maintaining the “changeTime” column in the aging table together with an implementation that updates the changeTime for a group each time it is acted on by a management function in the API.
Finalize logging requirements and functional specification for phase 3 capabilities.
Adds support for aging of groups and of group memberships.
3.5. Batch applications exercising aging
These basically are reports that report on aging status of groups and of group memberships.
Demo the UI and API capabilities to a selected small set of sites planning to implement Grouper, and get their feedback for incorporation into the design.
Maybe solicit a contributed implementation guide, leaving the working group to write API and UI usage guides. In addition to documentation of the publically exposed API, the API usage guide should include information on how to extend group types and how to extend the API to enable use of multiple membership fields, should a site wish to make use of these capabilities in the Groups Registry.
[1] “Group Tools Architecture”, Tom Barton, editor, December 2003.
http://middleware.internet2.edu/dir/groups/docs/draft-barton-grouptools-arch-02.html