...
Team Members: Jacob (convener), Scott, Chris, TomB, Jimmy, whoever Dedra delegates
...
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.
...
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.
...
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 faced by each enterprise. 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.
Recommendations
1. Use the KIM service interfaces as the starting point for defining how core access management objects are communicated between systems in the OSIdM4HE suite, and enhance them as may be needed over the course of implementing integrations between elements of that suite so that at all times they represent the current service contract for core access management objects.
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.
2. The Grouper and Rice teams should adapt their existing means for vetting requirements, producing corresponding updates to their roadmaps, and eventual design and implementation, to recognize when a requirement impinges on the KIM embodiment of the service contract for core access management objects. Further, they should create a venue and methodology for coordinated review of such requirements and determination of complementary design and implementation in their roadmaps.