Scribing Template --Friday, Oct 5, 2012 at 1pm Salon 6
.
TOPIC: Intersection of Kuali and CIFER
CONVENER: Eric Westfall from IU
SCRIBE: Jonathan Pass
# of ATTENDEES: 12
MAIN ISSUES DISCUSSED
Kauli Background
- Kauli started as a financials tool (KMS
- Copus - research admin, grants, proposals, awards, etc.
- Student - Curriculum development enrollment, admissions, registration, financial aid, etc.
- HR - time/attendance, leave and payroll core HR , benefits, time
- ...
Kauli RICE - development framework and middleware
- Service bus
- workflow
- Identity management KIM
- Identity
- access management
Kuali apps and non kuali apps interface with KIM APIs
Trying not to be prescriptive about IdM
Would like to leverage a standard (CIFER) interface to get Identity data.
KC=Kauli Covius
KFS=Kuali Fincials
KS=Kuali Student (number one priority for Kauli project)
Suggestions?
Kauli could cache the data from the IdM/Person Registry
A view identity data for KFS vs KC might differ
Discussing the option of splitting the identity data used in different Kuali modules.
Kuali benefits today from having one database of identity in KIM
Kuali was built to be modular. Many schools choose to implement just KC.
Kuali student could feed into a central registry which is also populated by something like PeopleSoft HR.
KIM people get permissions and that may populate roles which could in turn get provisioned to AD.
One Kuali goal is to use KIM to manage roles. Both roles and groups appear in KIM.
Early on in Kuali they made a decision not to check membership in groups for access instead use the roles to define what someone can do in the application. However groups can be permitted to roles.
There is talk of defining standard APIs in CIFER that KIM could plug into.
KIM doesn't have a function for joining identities today
Concern about adopting Kuali and avoiding a collision with homegrown systems.
KC needed to know what a Faculty salary for some functions and there is a place to store that in KIM.
What information from the SOR goes into the registry/ what doesn't go into the registry.
Most of Kuali is RPC/SOAP based. CIFER is leaning toward REST. Kuali isn't opposed to REST but it hasn't been implemented. Moving into the future Kuali may support both. Advantages to using WSDL tools to generate SOAP interfaces is easy. Well so does CURL with REST.
-
ACTIVITIES GOING FORWARD / NEXT STEPS
- 
If slides are used in the session, please ask presenters to convert their slides to PDF and email them to acamp-info@incommon.org
Thank you!