1. Introduction to Kuali Rice Presented at Internet2 April 2009 Eric Westfall – Kuali Rice Project Manager Bill Yock – Vice Chair, Kuali Rice Board of Directors

2. 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)

3. 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

4. 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

5. Kuali Rice Components – Version 1.0 KNSKuali Nervous System KENKuali Enterprise Notification KSBKuali Service Bus KEWKuali 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

6. 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

7. KNS Development Paradigm CHART_T Chart (POJO) ORM Map Data Dictionary Lookups and Inquiries Maintenance Documents Transactional Documents Workflow (KEW)

8. 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

9. 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

10. Other KNS Features Data Dictionary Question component Notes and attachments Pluggable business rules KIM Integration for Authorization System parameters

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. Document Search Screen

20. Action List Screen

21. Route Log Screen

22. 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

23. 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

24. 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

25. KIM – Design Goals Provide a reference implementation of the services but allow for customization/replacement to facilitate integration with institutional services or other 3 rd party IDM solutions Allow for the core KIM services to be overridden piecemeal −For example: override the Identity Service but not the Role Service

26. 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)

27. 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)

28. 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

29. 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

30. 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

31. 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

32. 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”

33. 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

34. 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

35. 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)

36. KIM – Responsibility Service Example Service Operations: −Get responsibilities by name −Get responsibility actions −Get responsibility actions by responsibility template −Does principal have responsibility

37. 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

38. KIM – Architecture diagram

39. 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

40. 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

41. 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!

42. Further Information about Kuali Rice The main Rice web site −http://rice.kuali.orghttp://rice.kuali.org −Sign up for our public mailing list −Access to our wiki: roadmap, project plans, documentation, etc

43. Thank You! Any Questions? Contacts: Eric Westfall - ewestfal@indiana,eduewestfal@indiana,edu Bill Yock – byock@u.washington.edu byock@u.washington.edu