Kuali Identity Management - Introduction And Implementation Options
•Download as PPT, PDF•
0 likes•2,446 views
A presentation including a quick introduction to the Kuali Identity Management module of Kuali Rice followed by a discussion on integrating KIM with various other pieces of software.
![Kuali Identity Management: Introduction and Implementation Options ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Kuali Identity Management - Introduction And Implementation Options
Similar to Kuali Identity Management - Introduction And Implementation Options (20)
Recently uploaded
Recently uploaded (20)
Kuali Identity Management - Introduction And Implementation Options
- 1. Kuali Identity Management: Introduction and Implementation Options Jasig - Spring 2010 Wednesday, March 10, 2010 8:30 am
- 3. KIM Introduction Implementing Kuali Identity Management at your Institution
- 6. Why Did We Create KIM?
- 8. What we did not want KFS KC KS IDM IDM IDM
- 9. What we did want KFS KC KS KIM
- 11. KIM Terminology
- 14. KIM Services
- 20. KIM Integration Rice Database Reference Implementations OpenRegistry? Identity Service Responsibility Service Permission Service Group Service Role Service KIM Service Layer
- 22. KIM Integration Integration with various Identity Management Systems
- 38. with Federated Authentication Shibboleth Login Process
- 48. Microsoft Identity Lifecycle Management
Editor's Notes
- Welcome. This session is “Implementing Kuali Identity Management at your Institution” and is a pre-conference workshop that runs for three hours. We’ll be covering quite a bit of ground this morning, looking at both technical and financial aspects. We will take a short break about halfway through the workshop.
- The presenters are Eric Westfall from Indiana University and Dan Seibert from UC San Diego
- Now, while KIM is partially a service layer, it does have a complex system for managing roles within an organization. Now so much in the provisioning of those roles, but in the checking the applicability of the roles in a given situation.
- There are many different identity and role management systems out there. There are several commercial offerings and even more home-grown systems developed over the years. For the Kuali applications, and any applications developed on top of the Rice framework, it provides a layer of abstraction to insulate the application from needing to know the details of those systems. For KFS, this allows the implementation of the identity, group, and role definitions to be changed out without code changes on the part of the application. Prior to KIM, you would have to load the user table through a batch process, which would then need to be kept in sync as necessary. With the KIM service layer, you can leave the data in your system-of-record. KIM also provides a set of user interfaces. These are mainly useful when using the reference implementation although some aspects of the main person UI have been designed to work with external systems.
- KIM’s default implementation is more of a data storage system than a provisioning system. It does not have any built-in code to scan other systems for identity/role information. Those hooks would have to be built by your institutions. One of the things that some other systems (like the proposed JA-SIG Open Registry and Microsoft’s Identity Lifecycle Management) provide tools for aggregating identity data from multiple sources (HR system, Student system, etc.). So we may want to mention that KIM is not an identity aggregation system.
- When Kuali started, we had a single focus: KFS. About two years in, the KRA component started and we realized that we had build an infrastructure upon which we could build multiple systems but that infrastructure was embedded in KFS. From that, the Rice project was created and extracted. User maintenance was part of rice, but not in a way which would be usable between multiple enterprise-level systems. About two years ago, members from the Kuali projects met to discuss what would be needed for the projects to be able to use the Rice framework as a core going forward. In addition, a number of the original institutions were indicating interest in implementing both KFS and KRA. From those discussions, it was decided that a unified identity/roles/permissions system would be needed to prevent every Kuali application from going their own way as well as to simplify the implementation of multiple Kuali applications within a single institution. These also have to do with Rice as a whole. A challenge we had within the KFS in early versions was that the authorization component was very loose. We hadn’t defined all the ways in which we would need to apply authorization. And, as such, it was done in a myriad of ways. KIM unified our permission checking in KFS.
- When KIM was being designed, it was recognized that there were other entries in the market, many of which had been around for some time and had robust feature sets. We also knew that many institutions would not adopt a system which would require a change to their user maintenance infrastructure. So, KIM was defined as a set of services with fairly well delineated boundaries. This would allow institutions to use or override coherent portions of the system without having to understand the whole of KIM.
- KIM consists of a set of service definitions, available over the Kuali Service Bus, or more generically through SOAP web service calls for non-Kuali applications. A default implementation using the capabilities of the Kuali Nervous system for data persistence and UIs.
- Authentication Service Extremely simple client-only service. This service will never be remoted on the KSB. Just returns the principal name from the authentication system. Default works for most authentication systems that use the REMOTE_USER header. You may want to override this if you need to perform some translation on what your authentication method returns if it is not what you use in your identity system. Identity Service This service is responsible for nothing more than the lookup and retrieval of entity information. It’s unaware of any of the other services. All the other services use this one for retrieval of entity/principal information when needed. Group Service Role Service This one is not often used directly. All the checking within the application is done in terms of permissions. The permissions are then linked to roles which the permission service accesses. Permission Service This is the most heavily used service in the KNS. It’s API methods are centered around running authorization checks. Responsibility Service Used almost exclusively by the workflow engine for determination of routing.
- Identity Management Service This service is a wrapper around the identity, group, permission, and responsibility services. It is intended to run locally within the Rice client application. It will access the other services off the Kuali Service Bus as needed. It provides caching of results locally to prevent expensive network access. It also has some API methods to purge portions of the cache as needed. Roles are not in this service mainly to enforce the nature of permission checks. (Previously, many “permission” checks were done by checking the user’s membership in a group (pre-KIM). This separation was made so that explicit role checks must be a conscious decision on the part of the developer. Role Management Service This service is to roles what the IdM service is to the other four services. Person Service The person service provides an abstraction and simplification of the KIM data model for use by the core KNS components. Most usage of person/entity data is covered by the data attributes on the person object. It takes the default information from the Entity/Principal and mostly flattens it into a simpler object. Within the KNS, in most cases, only the Person object is used. Identity Archive Service This optional service sits behind the identity service. It’s purpose is to archive a very limited subset of the most current data on each principal that it sees. If the user is ever removed from the identity management system completely, the data will be pulled from this service so that information like principal name, entity name, and email address can still be displayed on old document route logs.
- Identity Management Service This service is a wrapper around the identity, group, permission, and responsibility services. It is intended to run locally within the Rice client application. It will access the other services off the Kuali Service Bus as needed. It provides caching of results locally to prevent expensive network access. It also has some API methods to purge portions of the cache as needed. Roles are not in this service mainly to enforce the nature of permission checks. (Previously, many “permission” checks were done by checking the user’s membership in a group (pre-KIM). This separation was made so that explicit role checks must be a conscious decision on the part of the developer. Role Management Service This service is to roles what the IdM service is to the other four services. Person Service The person service provides an abstraction and simplification of the KIM data model for use by the core KNS components. Most usage of person/entity data is covered by the data attributes on the person object. It takes the default information from the Entity/Principal and mostly flattens it into a simpler object. Within the KNS, in most cases, only the Person object is used. Identity Archive Service This optional service sits behind the identity service. It’s purpose is to archive a very limited subset of the most current data on each principal that it sees. If the user is ever removed from the identity management system completely, the data will be pulled from this service so that information like principal name, entity name, and email address can still be displayed on old document route logs.
- Now, while KIM is partially a service layer, it does have a complex system for managing roles within an organization. Now so much in the provisioning of those roles, but in the checking the applicability of the roles in a given situation.
- However, they are using multiple authentication mechanisms – native Active Directory, Shibboleth, and Central Authentication Service. In order to implement KIM, even in this relatively simple but non-Kuali case, custom connectors will have to be written to pull data from PeopleSoft. Additional work will need to be done on the Active Directory side. Fortunately, Indiana has already completed or is in the process of completing most of this work. Eric will talk about this in more detail when we get to the case studies near the end of the workshop.
- It’s also possible to integrate Kim with your institutions LDAP server. A few institutions have already done this. Including UofA, SJDC, and UCDavis. Another approach would be to use CAS and configure CAS to connect to LDAP datasource Let’s take a closer look as UofA’s implementation
- To ease their implementation, they chose to use the Spring LDAP module. Spring LDAP is an adapter layer between Spring and LDAP datasources. The LdapTemplate class encapsulates all the plumbing work involved in traditional LDAP programming In addition, they used the Kim parameter service to map between KIM and their EDS system. By using these tools, most of the work is a configuration task. Some programming is still required: To implement and override the KIM Identity service In addition, they still wanted to use the Rice UI screens to add and update principals in the system, so they also overrode the UIDocumentService. This service is a layer below, the services we’ve discussed so far.
- Modifications to the edu/arizona/kfs/sys/spring-sys.xml Modify the spring config files to define the following beans
- Modifications to the edu/arizona/kfs/sys/spring-sys.xml
- Spring LDAP is an adapter layer between Spring and LDAP datasources. The LdapTemplate class encapsulates all the plumbing work involved in traditional LDAP programming Setup Spring LDAP Implement/Override
- loadEntityToPersonDoc is used to populate the IdentityManagementPersonDocument when the page loads from “edit” or “create new”. Even though entity information is not being stored in the database, it still needs to be present on persons. saveEntityPerson is used to store the information and actually update the person. It needed to modified to take into consider the check for the “ Modify Entity” permission. Normally, even if the permission isn’t present, the document will try to save entity information. By checking for this permission, the desired behavior takes place which is entities
- Shibboleth can be used a few different ways to provide authentication and authorization functionality across or within institution boundaries. It allows sites to make informed auth decisions for protecting online resources. Some ways that Shibboleth could be used with a Kuali Rice application are: …
- This slide illustrates the flow of a typical federated logic process using Shibboleth. I won’t go into too much detail here, but the process involves: - User attempt to access a Shibboleth protected site. The user is re-directed to a service which determines where the user is from, and then redirects them again to their home institutions authentication service. Once the user is authenticated, they are redirected back to their original site, there login credentials are passed to the site along with the request. The site then knows that the user has authenticated with a trusted resource, and can access the credential attributes to make authorization decisions.
- Shib filters: for apache: mod_shib, mod_proxy_ajp - forwards HTTP request from the web server to the servlet container (tomcat) Shib config file: shibboleth2.xml <RequestMap> <Session Initiator> <WAYF> <ERRORS> Config settings: set behavior of filter – Auth Type, require, Implement AuthenticationService to retrieve the Shibboleth attributes and authenticate the user. You may need to implement some logic =
- Name is the attribute name as provided by the identity provider Header is the name of the HTTP header, that will carry the attribute value Alias is a more convenient shorter name to be used in Apache configuration (see below) It is also possible, by using proper <SiteRule> and <Value> elements to restrict attributes to some origins (identity providers) or values only.
- A different scenario is to use your KIM module to authenticate users for other applications.
- We are all here, as representatives of educational institutions and their commercial affiliates, to address common problems related to computing services in higher education. Several communities and consortiums have developed various open source solutions. Kuali Rice and Internet2’s Grouper are examples of these. An interesting progression now, is how to take some of these solutions and use them together to create something richer than each provides on its own. Recently, the Kuali Rice team and the Internet2 Grouper team met and collaborated on how to delegate from Kuali Rice to Internet2 Grouper. Specifically, Chris Hyzer of University of Pennsylvania worked with the Kuali Rice Team to develop adaptors that integrate the Rice KIM module with Grouper.
- Rice offers pluggable service interfaces. Grouper provides a thin client for remote communication. This project implements the Rice group services to delegate to the Grouper client.
- Installation of the KIM/Grouper Adaptors is relatively simple, if you already have a Kuali Rice application and Grouper installed. Copy jars to the rice applications library directory. kr-dev/WEB-INF/lib copy the properties file to webapp directory …/WEB-INF/classes Edit the properties file to set the WS connect string to the Grouper WS at your institution. Also customize the grouperKIMConnector settings - Override the kim group and Identity services
- To override a KIM service, simply modify the appropriate spring config file to create a new bean with the ID, and class. Collaborative efforts are what make Internet2 and Kuali work. Within higher education, many of the problems we each face are similar, both technical and financial. Collaborative efforts such as these, are vital to providing enterprise level software solutions to our institutions.
- Current branding of this tool is “Forefront Identity Manager”