Below is a summary of possible KIM Integration models that were gleaned from presentations and discussions with implementors at the Kuali Days VIII conference:
KIM Integration Model | Pros | Cons |
|---|
#1 (Internal DB) | - Out of box implementation
- No custom KIM service implementation
| - No IDM integration
- Must re-enter all person identity manually
- Must manually keep identity data synchronized
|
#2 (Data feed) | - Authoritative IDM source data is utilized
- No custom KIM service implementation
| - Must create a synchronization/push process
- Delay is source data propagation *
|
#3 (Service - LDAP backed) | - Real-time data currency
- Authoritative IDM source data is utilized
| - Custom KIM service implementation
- LDAP data source must make all attributes available
- Requires good performing LDAP service
- Introduces external dependency for real-time data access
|
#4 (Service - DB backed) | - Real-time data currency
- Authoritative IDM source data is utilized
| - Custom KIM service implementation
- Database data source must make all attributes available
- Requires good performing database service
- Introduces external dependency for real-time data access
|
Institution Implementations
Intuition Institution | Identity | Group | Role/Permission/Responsibility* |
IU | #2 (10 minutes) | #1 & #2 (AD groups) | N/A |
CSU | #2 (nightly) | #1 | N/A |
Arizona | #3 | #1 | N/A |
SJD | #3 | #1 | N/A |
NPS | #3 | #1 | N/A |
UCD | #3 | #1 | N/A |
UCM | #4 | #1 | N/A |
- Due to the complexity of the KIM type functionality, it is recommended that Role, Permission and Responsibilities services remain as the default KIM services. By utilizing KIM types you can integrate into other external systems rather than overriding these specific services.