Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Kuali Identity Management Introduction Kuali Identity Management (KIM) is an infrastructure component of the Kuali suite. It is currently being developed with the concept that it could exist as a component to serve as an identity interface to the Kuali applications within a larger campus identity management concept, or it may provide all the identity management functionality for the campus. The scope of the KIM design includes authentication, authorization, and single sign-on support. The target completion date for KIM implementation is early spring 2009. UCSB Identity Background UCSB is currently engaged in a project to implement the SUN Java Enterprise Suite Identity Management system (SUN IdM). Figure 1 provides a conceptual overview of how the SUN IdM implementation is envisioned to support UCSB identity needs. t en ts ud n St lica p Ap Id Provision Public Identity database iv Pr IC LDAP (Active Identites) SUN Access Manager Single Signon Management Enterprise LDAP (Active Identities) Authorization Request on isi sion vision rovi Identity Pro Id P Account Activation Password Reset Role Management Other Manual Functions Identity Database (secure source of truth) Id Employee Data Feed es iat ffil ed A r Fe he Ot Data Identity Management Process Authentication Request St ud en Fe t Da ed ta ... UCSB Application Other Identity Data Stores (Active Identites) Figure 1: Overview of UCSB Identity Management Components The scope of the UCSB IdM Project is to implement enterprise level identity management tools that provide support for collection and management of identity data, provisioning of identity stores with subsets of the collected data, authentication, common sign-on, authorization and tools that allow users to activate accounts, change passwords, and maintain role definitions and memberships both directly and in a delegated fashion. KIM Description Kuali Identity Management (KIM) is being implemented with the concept that KIM may provide enterprise level identity management support for a campus, or KIM may provide an interface between an existing campus identity management system and the Kuali suite of applications. KIM apparently provides authentication, single sign-on, and authorization support as well as role definition and role membership management capabilities. It is unclear whether KIM will provide the ability to provision data to subordinate identity data stores or support the concept of account activation, account management or delegation. KIM utilizes infrastructure components of Kuali RICE. Figure 2 depicts the KIM concept. Figure 2 – KIM Concept KIM – IdM Integrated Environment Within the context of Sun IdM, KIM becomes a provision target for identity data. In addition, KIM may be a provision target for role data or KIM may be viewed as the source of truth for role data associated with financial business processes. In the integrated environment, we assume that KIM is only providing an interface between IdM and the Kuali applications being utilized at UCSB. The current RICE implementations define facilities to allow institutions to integrate KIM with their enterprise identity management system. To achieve the integration, one would have to make slight modifications to the identity filters provided with the baseline KIM product. However, these modifications are anticipated by the KIM architects and are not considered changes to the core of Kuali. See Appendix I for details of the approach to UCSB IdM – KIM integration. KIM as UCSB IdM While the KIM design seems to indicate that KIM is capable of providing standalone identity management functionality, there are components of the UCSB Sun IdM concept, such as provisioning, account activation, password reset and a robust authorization structure that likely could not be supported by KIM. Those features could probably be implemented locally, but local implementation represents a maintenance cost. In addition, the KIM based implementation would use an enterprise level LDAP as the source of truth for identity data rather than the secure relational database utilized in the UCSB Sun IdM architecture. Assuming KIM functionality was acceptable as UCSB enterprise identity management, the biggest challenge would be integrating commercial and non-Java applications into the environment to support authentication and single sign-on. The most efficient approach to those interfaces would probably be a portal environment in which the portal becomes the single point of interface between applications and the identity system for the purpose of authentication and single sign-on. There is collaboration between the Kuali technical community and the UPortal technical community, so UPortal would probably be the most reasonable portal choice. While using KIM and Uportal as an integration framework is an obvious question, neither of those two communities discuss such scenarios as a priority. There is a general working assumption that campuses and organizations buy into such technologies for other reasons before standards compliance. At this point, KIM based authorization is not well enough understood to determine how campus functions would integrate with KIM authorization. KIM Operational Environment Operationally, the KIM environment would probably require the same characteristics in staff and hardware resources to support UCSB Sun IdM, but in an increased quantity. The staff required to support KIM would include: Software engineers to support the code base, Software analysts / technicians to support identity data feeds to the database Database management engineers to support the KIM database Customer relationship and technical support Technology to support KIM would also be similar to the technology to support UCSB Sun IdM. The following technology would be required: Virtual machine infrastructure KIM Server (Linux, TomCat) KIM Database Server – MySQL (Oracle not an option at UCSB) Conclusion The most appropriate use of KIM at UCSB would be as an interface between the UCSB IdM and financial systems identity. Substantial local development would have to be undertaken in order to make KIM compatible with current enterprise level IdM requirements such as eliminating ambiguity within identity data sources, account activation, delegation, and password management. APPENDIX I UCSB Identity Management and Rice Rice or Rice embedded within KFS has a number of services that can be overridden to accommodate links to institutional Identity Management. For example, the current version of rice (0.9.4) has 2 packages for this purpose, however this is a work-in-progress. The first is the API or Java interface where the source code is contained in the package org.kuali.rice.kim.service. The second package is the Java implementation for these interfaces and the place where we can add our own overridden customizations in a non-Kuali package. This Kuali package is called org.kuali.rice.kim.service.impl Rice-0.9.4-br Api/src/main/java org.kuali.rice.kim.service org.kuali.rice.kim.service.AuthenticationService.java org.kuali.rice.kim.service.GroupService.java org.kuali.rice.kim.service.IdentityManagementService.java org.kuali.rice.kim.service.IdentityService.java org.kuali.rice.kim.service.IdentityServiceBase.java org.kuali.rice.kim.service.PermissionService.java org.kuali.rice.kim.service.PersonService.java org.kuali.rice.kim.service.ResponsibilityService.java org.kuali.rice.kim.service.RoleManagementService.java org.kuali.rice.kim.service.RoleService.java Impl/src/main.java org.kuali.rice.kim.service.impl org.kuali.rice.kim.service.impl.AuthenticationServiceImpl.java org.kuali.rice.kim.service.impl.GroupServiceImpl.java org.kuali.rice.kim.service.impl.IdentityManagementServiceImpl.java org.kuali.rice.kim.service.impl.IdentityServiceImpl.java org.kuali.rice.kim.service.impl.KimModuleService.java org.kuali.rice.kim.service.impl.KimUserServiceImpl.java org.kuali.rice.kim.service.impl.KimWorkgroupServiceImpl.java org.kuali.rice.kim.service.impl.MaxAgeSoftReference.java org.kuali.rice.kim.service.impl.PermissionServiceImpl.java org.kuali.rice.kim.service.impl.PersonServiceImpl.java org.kuali.rice.kim.service.impl.PrincipalDerivedRoleTypeServiceImpl.java org.kuali.rice.kim.service.impl.ResponsibilityServiceImpl.java org.kuali.rice.kim.service.impl.RoleManagementServiceImpl.java org.kuali.rice.kim.service.impl.RoleServiceImpl.java org.kuali.rice.kim.service.impl.UiDocumentServiceImpl.java The Kuali Identity Management Service is the main entry to other identity related services. As of today, it has a Spring context which includes the following services: protected protected protected protected protected AuthenticationService authenticationService; PermissionService permissionService; ResponsibilityService responsibilityService; IdentityService identityService; GroupService groupService; public interface IdentityManagementService /** * This is the front end for the KIM module. Clients of KIM should access this service from * their applications. If KIM is not running on the same machine (VM) as the application * (as would be the case with a standalone Rice server), then this service should be implemented * locally within the application and access the core KIM services * (Authentication/Authorization/Identity/Group) via the service bus. * * For efficiency, implementations of this interface should add appropriate caching of * the information retrieved from the core services for load and performance reasons. * * Most of the methods on this interface are straight pass-thrus to methods on the four core services. * * @author Kuali Rice Team ([email protected]) * */ Here are the steps necessary to integrate to a single-signon application: The AuthenticationServiceImpl has a method called getPrincipalName, which calls a class called KualiCasFilter.getRemoteUser(request) which retrieves header variables for the authenticated user. Here at UCSB we are currently using Netpoint, so a new class could be created called KualiNetpointFilter or in the case of Sun’s OpenSSO we could create a class called OpenSSOFilter. This class contains a number of different methods that will need to match the UCSB implementation and the header variables that are assigned within the SSO application. There is also a method called redirectToCas in the AuthenticationServiceImpl, which will redirect to the CAS login page, so this will also need to be customized depending on the system we decide on. public String getPrincipalName(HttpServletRequest request) return (request.getRemoteUser() == null) ? KualiCasFilter.getRemoteUser(request) : request.getRemoteUser(); An Authentication filter must also be added to the web.xml file of the Kuali instance UCSB will run. Here is an example of this change using CAS as a model: Web.xml <!-- Notification System filters --> <!-- CAS filter --> <filter> <filter-name>CAS Authentication Filter</filter-name> <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class> <init-param> <param-name>targetBeanName</param-name> <param-value>casAuthenticationFilter</param-value> </init-param> </filter> <!-- Another CAS filter --> <filter> <filter-name>CAS Validation Filter</filter-name> <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class> <init-param> <param-name>targetBeanName</param-name> <param-value>casValidationFilter</param-value> </init-param> </filter> <!-- CAS filter that wraps the servlet request --> <filter> <filter-name>CAS HttpServletRequestWrapperFilter</filter-name> <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class> <init-param> <param-name>targetBeanName</param-name> <param-value>casHttpServletRequestWrapperFilter</param-value> </init-param> </filter> configured to talk to our LDAP: C A S w i l l a l s o n e e d t o b e UCSB LDAP Mapping to KIM UCSB LDAP Attribute KIM Attribute Data Example Principal 19f96896-24a0-11d7-9d17-0004ac49346e employeeNumber employeeId 999999999 Ucsbaffiliation EntityAffiliationId employee,student ucsbCampusID Other LDAP Attributes that may be needed: uid ucsbpseudouid ucsbcompleteid1 cn sn givenName initials employeeNumber mail departmentNumber ucsbhomedepartment displayName The Kuali Foundation site has documentation to install CAS using Spring security all connected to an LDAP. Install and Configure ACEGI, CAS, LDAP, and Shibboleth https://test.kuali.org/confluence/display/KULRICE/Install+and+Configure+ACEGI %2C+CAS%2C+LDAP%2C+and+Shibboleth UCSB Current Production Authentication: Netpoint SSO which interfaces to the campus LDAP. Other Authentication Options: JES/Open SSO Netpoint - SSO CAS – SSO UCSB Current Production Authorization: ALLN01 – Mainframe ADABAS based financial authorization. Star Security– Mainframe based ADABAS based Student authorization. FlexCard Management – SQL Server based authorization. OnLine GL – SQL Server based authorization. Other Authorization Options: Use KIM Database for Roles, etc. May 06, 2008