Objective

Define a standard mechanism for SORs (SORs) to exchange data with Identity Registries/Identity Management Systems (IdMSs).

Background

Generally, SORs provide large amounts of data about a person (biodemographic data used for identity matching, such as name, date of birth, and identifiers; and role data used for directories and privileges, such as titles and addresses). In return, IdMSs return relatively limited data to the SOR, usually restricted to identifiers (such as NetIDs and email addresses). By establishing a standard way to exchange this data (via batch or real time mechanisms), integration costs between SORs and IdMSs can be reduced.

For this document, the Identity Registry ("registry"), a repository of data uniquely identifying individuals across an enterprise, is considered the key component of the IdMS.

General Use Cases

  1. Registry up front (person is added to registry prior/synchronous to SOR add)
  2. Registry later (person is added to SOR, then passed to registry)
  3. Direct Integration (SOR directly queries registry for person data)
  4. Master Data management (an external product is responsible for uniquely synchronizing person data across SORs and the IdMS)

Integration Diagram

sor-registry

Immediate Discussion Topics

  1. Identify initial use cases to enumerate
  2. Review common API models and identify common themes on attributes for core schema proposal (eduPerson, COmanage, KIM, CPU, OR, PESC, SCIM, OpenSocial/VOOT, etc)

Parking Lot

  1. What does the actual protocol look like? Does it make sense to start with something like SCIM or OpenSocial/VOOT?
    1. Start with pseudo apis, then pick something from there. Then hack up a POC.
  2. What about batch operations (both multiple operations over r/t and file based)?
  3. Asynchronous API operations?
  4. Will there be “standard” or “core” attributes? If so, what will they be? eduPerson++?
    1. KIM has some standard items in it, but there has been talk that we could easily gather a list of core HR and Student attributes with those two Kuali projects. I know from the KS side, alignment with PESC standards has been put forward as a requirement.
    2. Here is the IMS Global Enterprise representation of Name (see 3.3.4) http://www.imsglobal.org/enterprise/entv1p1/imsent_bindv1p1.html#1426593
  5. Account recovery
  6. Can an SOR pull more general information? eg: the combined Person record showing all SORs’ data?
    1. Maybe this is the Circle of Life Diagram “CIFER Person API” vs “CIFER SOR API”?
  7. Figure out how PSU deals with mapping of address to “role” vs. simple typed address in CPR. What does the “group id” represent on the address table in CPR? Matt will follow up with Jimmy on this.
    1. from Jimmy “The group_id is used to allow for multiple addresses of the same type. For example with our multiple campuses, we have folks who have multiple work addresses. So the group_id allows us to group them together.” Talking a little further on this, there is no current mapping of address, etc. to role. -Matt
    2. from Renee “But it is certainly a use case we have at Penn State. We have discussed with folks at our med center as well as others.” -Matt
    3. OR attaches address to roles, which in turn are attached to SORs
  8. What does the piece that sits between the SOR and the SOR api look like? In many cases, the SOR won’t be able to call the api directly because it’s a vended product. Does this fall into the realm of provisioning? Should we be looking to define standards for standard events generated by the SOR or standard changelog format which can be slurped up by provisioning engine?
  9. Discussion of downstream provisioning from registry.
    1. ID change, for example (i.e. merged two records)
    2. Do we need to define a standard on events originating from the registry which can be plugged into for downstream provisioning purposes?
  • No labels