Uploaded image for project: 'Kuali Rice Roadmap'
  1. Kuali Rice Roadmap
  2. KRRM-94

Expand KIM functionality to incorporate full Identity and Access Management capabilities

    Details

    • Type: Rice Research Item
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: Unspecified Future Release
    • Component/s: KIM
    • Labels:
      None
    • Rice Theme:
      Kuali Application Business Drivers
    • Priority Score:
      0
    • Functional Justification :
      Hide
      The following are a compilation of various improvement requests that have been noted from the Univ. of Washington and from various discussion lists. The reference to the acronym ASTRA refer to UW's internal application authorization control system.
       
      IMPROVEMENTS TO SIMPLIFY OVERRIDING SERVICES

      In general it would be helpful to have simplified integration services or data providers with a small number of methods that could be implemented to provide integration with external systems. The primary service interfaces in KIM that would need to be implemented to integrate with an external system are all fairly complex, with a large number of methods, but only a subset of these really access data from the database. Identifying the subset of methods that need to be implemented if the data source changes would be helpful, and abstracting this further into a data provider interface would be even better.

      1.RoleService currently has 38 methods - to override this service to provide roles from an external system (like ASTRA) is a complex and error-prone task.
      2.ResponsibilityService has 12 methods
      3.IdentityService has 25 methods
      4.PermissionService has 24 methods

      Additionally, there are lots of exceptions where each of these services calls directly to another service's data access object, so integrating with an external identity management service, for example, requires overriding not just the IdentityService, but also the Responsibility and Group services.

      BUILT IN WEB SERVICE DATA PROVIDERS

      A natural extension of the above enhancement to simplify the work of overriding KIM services would be to provide a basic implementation of each external data provider service that would allow an institution to wire up a web service as the source of that data.

      In our case, this would mean a RoleProvider that could rapidly be configured to talk to the ASTRA web service via SOAP (or REST), and to make the necessary manipulations to the data to adequately map distinct concepts.

      ADDITIONAL CACHING OF EXTERNALLY PROVIDED DATA

      Organizing KIM to bring in data from external systems requires rethinking the caching strategy, which currently is organized in favor of having Rice client applications that talk to higher-level 'management' services that cache source data from services like IdentityService or RoleService that are uncached. But when connecting to external systems (like our PersonRegistry), it may be desirable to build in another layer of caching on the server (for example, in the IdentityService itself, rather than the IdentityManagementService) to reduce the load and improve performance when connecting out to external systems.

      A good example of this is our LDAP integration (contributed by University of Arizona), to which we had to add additional caching to provide reasonable performance when talking to the PersonRegistry. This work should probably be done once by the Foundation and not repeatedly by each implementing institution that requires identity data to come from an external source.

      ABILITY TO ORGANIZE ROLES/GROUPS HIERARCHICALLY

      In the case of our SAGE (Research Admin System) Advance Budget Request workflow, there was a need to map organizational structures, which are hierarchical, but KIM currently provides no clear mechanism to inherit and override responsibilities or permissions from one Role to another or from one Group to another. This is directly related to KOM (Kuali Organizational Management) enhancement requests. KIM and KOM will need to be interoperable.

      ACCESS MANAGEMENT FUNCTIONALITY

      Currently we use ASTRA to manage access to our services and applications, and there is no built-in support in KIM to grant a user permission to access a service or application. Adding that ability would make KIM more of a full-featured identity and access management solution. The ability to automatically provision and deprovision accounts via a workflow approval process is one of the most powerful features an access management system could provide. All institutions struggle with this. Access managed via roles and responsibilities to domains of data, versus applications or systems, is a model that is useful for controlling access to data available in data warehouses and reporting systems. Many applications require access to be restricted to both columns (classified data) and rows (span of control). An access management system should have an ability to have rules defined around both column and row permissions to data via specific roles.

      FEDERATED IDENTITY MANAGEMENT

      Improvements to support federated identity management services for lookup, matching, resolving identities between inter institutional KIM repositories has been discussed. Close integration with 3rd party identity providers like InCommon is desired. The management of student identitities across K-24 has been discussed as possible state mandates which would require federated identity management. Federation for researchers across institutions is becoming more common.
      Show
      The following are a compilation of various improvement requests that have been noted from the Univ. of Washington and from various discussion lists. The reference to the acronym ASTRA refer to UW's internal application authorization control system.   IMPROVEMENTS TO SIMPLIFY OVERRIDING SERVICES In general it would be helpful to have simplified integration services or data providers with a small number of methods that could be implemented to provide integration with external systems. The primary service interfaces in KIM that would need to be implemented to integrate with an external system are all fairly complex, with a large number of methods, but only a subset of these really access data from the database. Identifying the subset of methods that need to be implemented if the data source changes would be helpful, and abstracting this further into a data provider interface would be even better. 1.RoleService currently has 38 methods - to override this service to provide roles from an external system (like ASTRA) is a complex and error-prone task. 2.ResponsibilityService has 12 methods 3.IdentityService has 25 methods 4.PermissionService has 24 methods Additionally, there are lots of exceptions where each of these services calls directly to another service's data access object, so integrating with an external identity management service, for example, requires overriding not just the IdentityService, but also the Responsibility and Group services. BUILT IN WEB SERVICE DATA PROVIDERS A natural extension of the above enhancement to simplify the work of overriding KIM services would be to provide a basic implementation of each external data provider service that would allow an institution to wire up a web service as the source of that data. In our case, this would mean a RoleProvider that could rapidly be configured to talk to the ASTRA web service via SOAP (or REST), and to make the necessary manipulations to the data to adequately map distinct concepts. ADDITIONAL CACHING OF EXTERNALLY PROVIDED DATA Organizing KIM to bring in data from external systems requires rethinking the caching strategy, which currently is organized in favor of having Rice client applications that talk to higher-level 'management' services that cache source data from services like IdentityService or RoleService that are uncached. But when connecting to external systems (like our PersonRegistry), it may be desirable to build in another layer of caching on the server (for example, in the IdentityService itself, rather than the IdentityManagementService) to reduce the load and improve performance when connecting out to external systems. A good example of this is our LDAP integration (contributed by University of Arizona), to which we had to add additional caching to provide reasonable performance when talking to the PersonRegistry. This work should probably be done once by the Foundation and not repeatedly by each implementing institution that requires identity data to come from an external source. ABILITY TO ORGANIZE ROLES/GROUPS HIERARCHICALLY In the case of our SAGE (Research Admin System) Advance Budget Request workflow, there was a need to map organizational structures, which are hierarchical, but KIM currently provides no clear mechanism to inherit and override responsibilities or permissions from one Role to another or from one Group to another. This is directly related to KOM (Kuali Organizational Management) enhancement requests. KIM and KOM will need to be interoperable. ACCESS MANAGEMENT FUNCTIONALITY Currently we use ASTRA to manage access to our services and applications, and there is no built-in support in KIM to grant a user permission to access a service or application. Adding that ability would make KIM more of a full-featured identity and access management solution. The ability to automatically provision and deprovision accounts via a workflow approval process is one of the most powerful features an access management system could provide. All institutions struggle with this. Access managed via roles and responsibilities to domains of data, versus applications or systems, is a model that is useful for controlling access to data available in data warehouses and reporting systems. Many applications require access to be restricted to both columns (classified data) and rows (span of control). An access management system should have an ability to have rules defined around both column and row permissions to data via specific roles. FEDERATED IDENTITY MANAGEMENT Improvements to support federated identity management services for lookup, matching, resolving identities between inter institutional KIM repositories has been discussed. Close integration with 3rd party identity providers like InCommon is desired. The management of student identitities across K-24 has been discussed as possible state mandates which would require federated identity management. Federation for researchers across institutions is becoming more common.
    • Impact if not Implemented:
      Applications or institutions looking to implement Rice will need to develop their own IAM capabilities or rely on other vended or outside products.
    • Priority - KFS:
      No Priority
    • Priority - KC:
      No Priority
    • Priority - KS:
      No Priority
    • Priority - Rice:
      No Priority
    • Effort Estimate:
      Very High ~ 2500 hrs

      Description

      Significantly expand KIM's functionality to incorporated automated target system role-based provisioning. It is acknowledged that this is a major effort, requiring significant levels of research, coordination and development and would be considered a future roadmap item.

      Reason: There is a growing need for a cost effective Identity and Access Management solution tailored for the higher education sector, either because of recent software buyouts (Sun/Oracle), outdated legacy solutions or expensive enterprise level solutions.

        Attachments

          Issue Links

            Activity

            Hide
            ewestfal Eric Westfall added a comment - - edited

            One question would be whether we add the implementation of provisioning tools to this list of IDM capabilities. I think we are going to work on a standardized provisioning API as part of the FIFER-API project (https://wiki.jasig.org/display/FIFER/API) so we could basically just work on providing an implementation for that API. In fact, one possibility we could consider is discussing with the group working on that if having us work on a reference implementation as part of KIM is of interest (assuming it aligns with our priorities and timeline). From what I've heard an open source solution for provisioning is one of the major IDM gaps in the FOSS space.

            Show
            ewestfal Eric Westfall added a comment - - edited One question would be whether we add the implementation of provisioning tools to this list of IDM capabilities. I think we are going to work on a standardized provisioning API as part of the FIFER-API project ( https://wiki.jasig.org/display/FIFER/API ) so we could basically just work on providing an implementation for that API. In fact, one possibility we could consider is discussing with the group working on that if having us work on a reference implementation as part of KIM is of interest (assuming it aligns with our priorities and timeline). From what I've heard an open source solution for provisioning is one of the major IDM gaps in the FOSS space.

              People

              • Assignee:
                byock Bill Yock (Inactive)
                Reporter:
                hsublett Hampton Sublett (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated: