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_T Chart

(POJO) ORM Map

Data Dictionary

Lookups and

Inquiries

Maintenance Documents

Transactional Documents

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,edu Bill Yock – byock@u.washington.edu