KIM Integration Models
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) |
|
|
#2 (Data feed) |
|
|
#3 (Service - LDAP backed) |
|
|
#4 (Service - DB backed) |
|
|
Institution Implementations
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 |
Naval Post-Secondary |
#3 |
#1 |
N/A |
UC Davis |
#3 |
#1 |
N/A |
UC Merced |
#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.