Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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

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.
  • No labels