Download Kuali Identity Management

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