Introduction to Kuali Rice

Presented at Internet2

April 2009

Eric Westfall – Kuali Rice Project Manager

Bill Yock – Vice Chair, Kuali Rice Board of Directors

What is Kuali Rice?

• Kuali: a humble kitchen wok (Malaysian origins)• Rice: a food staple

−Sits on the bottom of a dish−Not a very tasty meal by itself−Better with some cuisine on top

• KFS (Kuali Financial System) - Beef• KC (Kuali Coeus, Research Administration) - Chicken• KS (Kuali Student) - Seafood

• Rice is the foundation to hearty meals (aka enterprise software products)

Kuali Rice Vision

• Support the needs of the Kuali Application Projects−Foundational middleware components and services−Enhanced software development framework

• Leverage the middleware and development frameworks for building custom applications

• Achieve sustainability through community source development and adoption

• Iterate Rice architecture towards a Service Oriented Architecture

Kuali Rice Objectives

• To create standard APIs to Rice components• To design components which are modular• To provide a reference implementation based on

industry standards• To ensure intellectual property and open source

license compliance is maintained • To promote adoption by a wide variety of

institutions, primarily in higher education• To build a large community of interest with strong

sustainability

Kuali Rice Components – Version 1.0

• KNS Kuali Nervous System• KEN Kuali Enterprise Notification• KSB Kuali Service Bus• KEW Kuali Enterprise Workflow• KIM Kuali Identity Management

• We will now explore each of the components in more detail with a focus on the newest module of Rice, KIM

KNS Overview

• Provides reusable code, shared services, integration layer, and a development strategy

• Provides a common look and feel through screen drawing framework

• A document (business process) centric model with workflow as a core concept

KNS Development Paradigm

CHART_TChart

(POJO)ORMMap

Data Dictionary

Lookups and

Inquiries

MaintenanceDocuments

TransactionalDocuments

Workflow(KEW)

Transactional Documents

• These are data-entry centric documents or “transactions” that model the business processes

• Examples include: Proposal Development, Journal Entry, Payment Reimbursement

• Built on a case by case basis using the Kuali Rice tag libraries (encompass snippets of UI behavior):−Notes and attachments−Workflow route log (audit log)

• Integrated with workflow

Maintenance Documents

• No GUI programming required, user interface is rendered by framework

• These are used for maintaining data• An easy way to maintain support tables in a

database• Supports creation of new records and editing of

existing records• Examples include:

−Budget rates−Project codes

Other KNS Features

• Data Dictionary• Question component• Notes and attachments• Pluggable business rules• KIM Integration for Authorization• System parameters

Ken Overview

• Works with the action list to provide a single place for all university related communications−Workflow items come from KEW−Non-workflow items from KEN

• Non-workflow example items−Overdue library book−A concert on campus−Graduation checklists for seniors

KEN Overview - Continued

• Provides a secure and controlled environment for notifying the masses

• Eliminate sifting through email• Communication broker which provides any

combination of action list, email, or custom notifiers−Controlled by user preferences

• Audit trail for all messages just as in KEW

KSB Overview

• A common registry of services−Lists all services on the bus and how they can be

connected−Through simple Spring configuration, Java based

services can be “exported” from a rice enabled application as SOAP or Java Serialization over HTTP services

• Common service locator paradigm - access services remotely or locally

• Other “Rice Clients” can consume services published on the KSB

KSB Communication Models

• Synchronous = P2P : waits for a response• Asynchronous = messaging : fire and forget :

possible callback• Queues = single service retrieved from

redundant set of services; only one invoked• Topics = all services retrieved from

redundant set of services; all invoked

KSB Security

• Bus level : option to digitally sign, WS-Security used for SOAP services

• Service level security through Acegi−Service level, method level−User proxying through standard security models

(i.e. CAS, Kerberos)−Security context passed along (user, authn

token, roles)−Services can call authn/authz authority to

validate context

KEW Overview

• Provides a content-based routing engine.− Documents created from process definitions (Document Types) and

submitted to the workflow engine for routing− Routing decisions made based on the XML content of the Document

• Traditionally used for business transactions in the form of electronic documents that require approval from multiple parties. For example:− Transfer of Funds− Hire/Terminate Employee− Timesheet− Drop Course

• Composed of a set of services, APIs, and GUIs

KEW – Core Features• Action List (User’s Work List)• Document Searching• Document Audit Trail (Route Log)• Flexible process definition (Document Type)

−Splits, Joins, Parallel branches, Sub processes, Dynamic process generation

• Rules Engine• Email Notification

KEW – Core Features

• Notes and attachments• Wide array of pluggable components to customize

routing and other pieces of the system• eDoc Lite

−Framework for creating simple documents quickly• Plug-in Architecture

−Packaging and deployment of routing components to the Rice Standalone Server at runtime

Document Search Screen

Action List Screen

Route Log Screen

KIM - Overview

• The Kuali Identity Management module will be included and version 1.0 of Rice

• Provides identity and access management services to Rice and other applications

• Includes a service layer as well as a set of maintenance screens

• Supported Concepts include:−Entities and Principals−Groups−Roles and Permissions−Authentication

KIM - Why?

• As more projects began to use the Kuali Rice framework, we identified a need for a common API for Identity and Access Management

• Wanted to introduce the concept of Roles into Kuali, previously groups were used for authz

• Ease the implementation overhead for implementers working with multiple Kuali projects

• Results in one-time institutional customization of identity services for all Kuali projects

KIM – Design Goals

• Shared identity and access management services that all Kuali projects can use

• Generic enough to be used by non-Kuali projects• Provide a rich and customizable permission-based

authorization system• All services available on the service bus with both

SOAP and Java serialization endpoints• Provide a set of GUIs that can be used to maintain

the data

KIM – Design Goals

• Provide a reference implementation of the services but allow for customization/replacement to facilitate integration with institutional services or other 3rd party IDM solutions

• Allow for the core KIM services to be overridden piecemeal−For example: override the Identity Service but not the

Role Service

KIM – Terminology

• Entity – a Person or System which exists within KIM

• Principal - represents an Entity that can authenticate into the system

• Group – consists of one or more principals or other groups

• Permissions – ability to perform actions• Permission Details – additional information on a

specific permission used to further qualify it (i.e. permissions that are associated with a particular Document Type in KEW)

KIM – Terminology

• Roles – permissions are granted to roles, principals and groups are assigned to roles

• Role Qualifications – additional attributes on a role assignment that help to qualify the role member’s relationship to the role− i.e. a principal could be assigned the “Account Manager”

role with a qualification of “account # 12345”• Responsibilities – granted to a role, gives role

members responsibilities to perform certain actions (such as approving documents routed by KEW)

KIM – Services

• KIM consists of the following services which encompass it’s API− IdentityService−GroupService−PermissionService−RoleService−ResponsibilityService−AuthenticationService

• These are read-only, there are also “update” services which allow for write operations

KIM – Identity Service

• Responsible for Principals and Entities• Principals have a “name” which is intended to be

the user name they use to authenticate• All principals are associated with an entity• There can be different types of entities, including

Person and System• Entities can have custom attributes and IDs

attached to them

KIM – Identity Service

• Numerous pieces of data can be stored about an entity including: names, affiliations, external ids, employment information, address, phone, email, privacy preferences (FERPA), etc.

• Example Service Operations:−Get principal by id−Get principal by principal name−Get entity info by id−Get entity info by principal id−Get entity privacy preferences

KIM – Group Service

• All groups identified uniquely by id or namespace + name

• Supports nested groups• Groups can also have custom attributes associated• Example Service Operations:

−Get group by id−Get group by name−Get groups for principal− Is member of group−Get member group ids

KIM – Permission Service

• KIM has the concepts of Permission Templates and Permissions

• Permission Template represents some course-grained permission−Use Screen, Initiate Document, Maintain Records, etc.

• A Permission is created from a template and has more specific information identified on it’s permission details− for example “Initiate Document” of type “Transfer of

Funds”

KIM – Permission Service

• Evaluation of permissions is handled by the permission service. KIM provides plug points for implementing custom logic for permission checking−Example: permission checks based on hierarchical data

• Example Service Operations:− Is principal authorized by permission name w/details− Is principal authorized by permission template name

w/details−Get assignees for permission−Get authorized permissions for principal−Get ids of roles that have given permission

KIM – Role Service

• Roles can have members that are principals, groups or even other roles

• All members assigned to a role will be granted any permissions or responsibilities that are associated with the role

• Role membership can optionally be qualified• Example Service Operations:

−Get role by name−Get role qualifiers for principal−Get role members

KIM – Responsibility Service

• Provides integration of KIM with workflow engine via Responsibility Actions

• These define what actions the principal needs to take (i.e. approve, acknowledge, fyi) on workflow processes

• Responsibility details identity when these actions are applied during the routing process

• Responsibility Actions also provide delegation support (for both routing and permission delegation)

KIM – Responsibility Service

• Example Service Operations:−Get responsibilities by name−Get responsibility actions−Get responsibility actions by responsibility template−Does principal have responsibility

KIM – Authentication Service

• Provides authentication at the web tier of an application

• Informs the application of the principal name that has authenticated

• Default implementation just uses the “remote user” on the HTTP request

• Only one service operation −Get principal name

KIM – Architecture diagram

KIM – Graphical User Interface

• KIM provides numerous lookups and inquiries on data in the KIM data model

• Additionally, there are a few screens that are used for maintaining KIM data− Person− Group− Role

• When implementing, institutions can choose whether or not to use the reference implementations of these GUIs− i.e. an institution may already have a system for group

maintenance that they want to integrate with KIM on the service backend but not in the GUI

KIM – Internal Usage

• Many permissions exist that are used by KNS, examples:− Edit Document− Look Up Records− Use Screen− Create / Maintain Records

• KEW uses KIM permissions as well:− Administer Routing for Document− Blanket Approve Document− Route Document

• Even KIM uses permissions internally− Assign Role− Grant Permission

What’s Next for Kuali Rice?

• Release 1.0 coming very soon!• Enhanced Documentation• Standards

−JPA for data persistence

• Easier configuration and turnkey upgrades• Better compatibility between different Rice versions• KOM – Kuali Organization Management• And much more!

Further Information about Kuali Rice

• The main Rice web site−http://rice.kuali.org−Sign up for our public mailing list−Access to our wiki: roadmap, project plans,

documentation, etc

Thank You!

Any Questions?

Contacts:

Eric Westfall - ewestfal@indiana,eduBill Yock – byock@u.washington.edu