Groups and Permissions
- Former user (Deleted)
Unique use cases
As educators and technologists, our challenge is to build and connect tools to enable and amplify academic use cases. We aren't interested in reinventing the wheel. One of the ways in which academic requirements are unique is that we need to be able to model many different roles: responsibilities and privileges that depend upon both identity and context. I could be a student in one context, an instructor in another, a referee in yet another, and so on. In many enterprise IT systems, the notion of roles is limited to administrators and "regular" users. We also want to be able to model key academic relationships such as mentor, advisor, and peer-reviewer. Online social networks have grown explosively in recent years, but their relatively thin model of relationships does not serve our specialized uses.
In a large university, such roles may be assigned from hundreds of sources, and any range of policies may govern such assignments. Some roles are official, and others are ad hoc. To make matters more complex, collaboration between departments, schools, and even institutions around the globe necessitates roles that cut across boundaries that have traditionally been rigid in higher education. Likewise, every information system has its own notion of how those institutional roles should translate into access control within the system.
Our academic use cases also demand that we be able to provision groups and roles with flexible lifetimes. Some memberships have a fixed timeframe, such as a single section of a course, others may be open-ended, and still others may be perpetual.
A good survey of academic use cases for groups, roles and permissions is available in the Sakai project's Groups wiki space.
Sakai 2.x: groups management toolkit?
At some institutions, Sakai has become an informal system of record for course enrollments, because it permits the course maintainers to combine the official course roster with their own ad hoc memberships. This flexibility is a success from the standpoint of empowering the right people to get the business of the institution done, but the approach only works within the narrow scope of data that Sakai manages.
Another popular feature of Sakai is the ability to add a mailing list to any worksite you maintain. Before Sakai at many institutions, you could only get a mailing list if someone in IT set it up for you, and then only if it met the requirements justifying its upkeep. By moving the administration out to end-user maintainers, it opens the tool up to previously unserved constituencies and reduces the ownership burden on central IT.
Sakai 2.x has been used as an informal groups management system, even though it was not designed generally for that purpose. Integrating new systems to work with Sakai "groups" is a lot of work, and marshaling a source of memberships (such as the registrar) to provision Sakai memberships is even more work.
One of the themes of Sakai 3 development is that we should not build an immature capability if we have the option to pull in a well-designed open source subsystem to perform that function. We will evaluate available groups management toolkits and ensure that Sakai 3 is a first-class front-end for accessing and deploying groups and permissions.
Wide scope
Groups and permissions management has a university-wide reach. Our existing IT systems already deal with identities, roles, and permissions, but they each use their own internal mechanisms to do so, and keeping systems in sync is difficult. Creating direct system-to-system communication channels for sharing group and permission data is labor-intensive, brittle, and scales poorly. We want a means of centralizing both the provisioning of groups and the synchronization of groups and roles with any application we choose.
A groups and permissions toolkit necessarily sits at a level above Sakai 3 (ALEX), since ALEX is just one of potentially many systems that could make access decisions based on a canonical groups and roles repository.
Formal selection
Whenever contemplating an enterprise system with a potentially wide reach, we want to take deliberate measures to set our commitments appropriately and keep the scope manageable. We intend to follow a software selection process that spells out our expectations both of the system and the resources necessary to develop and operate that system.
In addition to documenting the criteria and the process itself, we will plan and execute integration experiments to check our assumptions and shed light on potential roadblocks. To reduce risks during our exploration and trial period, we will avoid involving systems that cannot afford the disruption of an experimental integration. Since Sakai 3 is still an R&D project, it is a suitable partner for an exploratory groups toolkit integration.
Adding new infrastructure requires the resources to plan, deploy, integrate, and support that infrastructure. NYU will devote a member of staff to identity management issues in general, and groups management in particular.
Considering Grouper
Grouper, an Apache-licensed groups management toolkit, is a project of Internet2. Their first release was in December of 2004, and their recent 1.5 release (December 2009) adds many interesting new features, including support for roles and role hierarchies. Arbitrary permissions may also be attached to roles or to memberships. Grouper will be the first subject of our integration trials.
From Grouper's website:With Grouper, individuals across campus manage the memberships of the groups they steward. Grouper keeps the group membership decisions in the hands of the business/group owners, access control in the hands of the application owners, and the technology management in the hands of the technologists.
Grouper organizes groups in a configurable hierarchy. For example, you could represent a section of "History of Western Art II" like this:nyu:courses:v43:0002:001 We can query systems across the university to determine the membership of this group, and keep it up-to-date. A thin layer of code written for ALEX would lookup the course by its path and read the list of members and their roles for the purpose of establishing access rights for ALEX users.
As another concrete example, Xythos (NYU Files) can use the Grouper data on course groups to establish shared file areas. When an ALEX user uploads a file for use in her course, Xythos will treat that file as shared with the course group. Even though ALEX and NYU Files are separate systems, they will be able to synchronize their respective management of access control.
Grouper exposes its functions via many interfaces, to facilitate different styles of integration. It can be scripted from a command shell, web services (both SOAP and REST), a Java API, XML import/export, and direct access to its database views.
Groups schema
Our groups management trial is also a trial of the schema we devise to model (some of) the structures of the university. This will be a matter of striking a few balances: the balance between breadth and depth, and the balance between prescriptiveness and flexibility to name two. The smart way to approach this problem is to follow the example set by institutions that have already covered this ground. For Grouper alone, we have access to case studies from Duke, Brown, and Newcastle University.
Duke's hierarchy is fairly narrow, with top-level groups for students and employees, as well as well-established hierarchies for departments and courses.
Group modeling is an area where we should be able to make a good start in well-known territory, i.e. the scheme for identifying courses lends itself readily to the establishment of a hierarchy.
Groups and permissions in Sakai 3
The permissions model currently available in Sakai's kernel (K2) is limited to filesystem-like permissions to add, modify, or remove content nodes. A subproject of K2 is underway to build the kind of rich permissioning necessary for academic applications (e.g., person A can grade assignment B). Even without rich permissions in place, we should be able to provision site memberships at least using external groups management, and do simple mapping to the basic contributor and administrator roles.
Mapping roles to permissions
The groups management toolkit we use will encapsulate the notion of roles that are meaningful to the institution, like "instructor," "student," "advisor," etc. It is up to the individual applications, such as ALEX, to determine what the institutional roles mean inside the application. In Sakai 2.x, there is crude support for role mapping by naming the role within each worksite that acts as "maintain." The challenge here is, how large do we allow the space of institutional group roles to become? Does the proliferation of roles become an integration bottleneck within our applications? Perhaps the answer is to allow group maintainers to specify their own mapping to well-defined application roles.
Role mapping is another area where we can follow the example of institutions that have traveled this path before. Duke's groups system governs the access rights for Confluence, Simba, web files, AFS, and Jabber.