introduction to kuali rice - internet2 to kuali rice presented at ... • service level security...
TRANSCRIPT
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
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 – 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 – [email protected]