This is the landing page for the Access Management Team for consolidating documentation, meeting agendas/notes, etc.
Team Members: Jacob (convener), Scott, Chris, TomB, Jimmy, whoever Dedra delegates
Points of discussion and recommendations
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 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 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.