This is the landing page for the Access Management Team for consolidating documentation, meeting agendas/notes, etc.
Subscribe to the CIFER Access Management list at https://lists.internet2.edu/sympa/subscribe/cifer-am
Team Members: Tom B (convener), Scott, Chris, Jacob, Jimmy, whoever Dedra delegates
Current Work Items
Summary of subgroup discussions
The access management "chunk", unlike the registries chunk, has existing open source products developed by the HE community with substantial capabilities and adoption: Grouper and KIM. And unlike the provisioning chunk, there is agreement across many projects and applications about the core objects of access management: groups, permissions (triples conveying whether a Subject can perform an Action on a Resource), roles (groups with one or more permissions), permission inheritance by subgroups of a role, making them superior roles, and more. Cf. the MACE-Paccman work.
Hence, the task of this subgroup was not a greenfield exercise in creating a high level design to meet a set of specified requirements, but rather a discussion that started with how the Grouper and KIM products and communities would relate to a larger IdM suite. Thus, the chief difficulty we faced was the overshadowing of established communities, practices, architectures, and implementations. Fear that one of these projects might find itself falling short on its commitment to their established community had to first be overcome.
The way out of that conundrum is the perspective that, although Grouper and KIM have overlapping capabilities, they are in fact complementary and composable, as has already been demonstrated by production implementation of integration technology co-developed by the Grouper and Kuali Rice teams. So in fact these two project teams have already demonstrated the kind of coordinated approach to meeting shared requirements and developing complementary technology that is the essence of the overall OSIdM4HE approach.
That integration was facilitated by substantial work previously done by the Rice team to design a set of service interfaces that together cover a wide range of access management needs by Kuali applications, so that that work should not be duplicated by each Kuali application team, and so that adopters of multiple Kuali applications should not face the burden of operating distinct access management services for each Kuali application. Do it one way that works for all.
Obviously, many applications run by HE are not Kuali applications, they are not designed to be composed with the KIM service interfaces, and so there remains the problem of integrating their access management needs with enterprise services in a way that is valuable, but that cannot approach the degree of integration achieved by the suite of Kuali applications with Rice, built with a common architecture, enabled by coordinated governance and shared resources. Many non-Kuali applications incorporate proprietary access management capabilities. These must be accepted by each enterprise as givens of the enterprise access management problem. This is a primary high level requirement of work in the access management space, and is what drives the Grouper project's strategy of providing an ever larger array of integration technologies that enable the core objects of access management to be managed in a common access management system and instantiated in an ever larger set of applications.
In particular, the Grouper and Rice projects should plan to build additional integration technology to enable the full range of core access management objects to be communicated between them.
More generally, the access management subgroup suggests to its peer subgroups that the KIM service interfaces be the starting point and stalking horse over time for the service contract needed to integrate with IdM registries and with provisioning systems. This would likely result in new types of service interfaces being added to those already in KIM, in addition to enhancing some of the existing ones.
Although this requirement is scoped to just these two projects, we suggest that this venue for coordinated review of shared requirements, potential enhancement to the KIM service interfaces, and determination of complementary design and implementation, should extend to other projects that become part of the OSIdM4HE effort. In effect, this is one venue in which cross-cutting integration needs are managed. This one is focused on on-going maintenance and enhancement of the KIM service interfaces. There might be others engendered by distinct integration needs among the suite of OSIdM4HE projects.