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)

  • 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
  • LDAP designed for quick searching and retrieval
  • 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
  • There may be entities that KIM needs that don't exist in LDAP (must provide way to look these up elsewhere)

#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 with special tuning to enable quick searches
  • Introduces external dependency for real-time data access

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

(star) 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.