draft

This document attempts to explain how various Identity Management related projects relate to each other. It is a draft based on project provided information, and may need refinement.

Goals of OpenRegistry

What is OpenRegistry?

OpenRegistry is an OpenSource Identity Management System (IDMS). Its a place for data about people affiliated with your organization.

Core Functionality

Interfaces for web, batch, and real-time data transfer
Identity data store
Identity reconciliation from multiple systems of record
Identifier assignment for new, unique individuals

Additional Functionality

Data beyond Persons: Groups, Courses, Credentials, Accounts
Business Rule based data transformations

More than just a Registry, some periphery too

Directory Builder
Provisioning and Deprovisioning

http://www.ja-sig.org/wiki/display/OR

Note that OpenRegistry is generally not authoritative for the data it maintains, it is a reflection of source data from authoritative systems of record processed to provide a single view of people data to consuming applications across the organization.

See also: http://www.ja-sig.org/wiki/display/OR/High+Level+Architecture

Goals of KIM

The Kuali Identity Management (KIM) system handles user identification, permissions, and responsibilities for multiple Kuali applications, including KFS. [...] [For example,] KFS communicates with KIM to determine each user's permissions and workflow responsibilities. These permissions and responsibilities are defined by the user's role or roles in the system. Roles can be customized to handle permissions and responsibilities in a variety of ways based on your institution's needs.

In KIM, each user is identified on the KIM Person document. This document identifies the person by a Principal ID and assigns that person to any number of roles. Role assignments may be made via the Person document or the Role document. Some types of roles, called "derived roles," automatically determine their members from data in other KFS components. For example, because Fiscal Officer is an attribute of the Account in the KFS, the Fiscal Officer role derives its assignees based on the data in the Account Table. You do not need to assign users to derived roles such as this one.

Groups provide another important tool in KIM. Groups are an optional feature that allows you to associate persons, roles or other groups with each other for the purpose of making role assignments. For example, if you want to assign the same role to three users, you could create a group, assign the three users to it, and then assign the group to the desired role. (Alternatively, you could add the three users individually to the role. The choice of whether to use a group or assign individual users to roles is entirely yours.)

Chapter 1: Kuali Identity Management (KIM), KIM Documentation (draft)

See also: http://rice.kuali.org/diagram.swf

Goals of OpenMetaDir

The first version of OpenMetadir was developed at Umeå University as a solution to a problem that many similar organisations face: That of co-ordinating the flow of information from a number of disparate sources like faculties, departments and administrative groups within the university and distributing this information to the proper recipients.

OpenMetadir can be used as part of an Identity Management System, it is what it was originally intended to be used as. But OpenMetadir as it stands today is really far more versatile and can be used to collect and distribute almost any type of information from almost any type of source to almost any type of recipient. This generality makes OpenMetadir a very powerful tool for consolidating information sources and making sure the right person gets the right information at the right time.

http://www.openmetadir.org/doc/info.pdf

Goals of Grouper

Grouper was developed as an open source toolkit to address the needs of managing groups. Grouper is designed to function as the core element of a common infrastructure for managing group information across integrated applications and repositories. Grouper combines multiple sources of group information, both automated and manual, in managing memberships and other group information in a Groups Registry, a central information asset complementary to a site's Person Registry.

http://middleware.internet2.edu/dir/groups/grouper

Goals of OpenLDAP

OpenLDAP Software is an open source implementation of the Lightweight Directory Access Protocol.

http://www.openldap.org

Goals of COmanage

COmanage is the Collaborative Organization Management Platform developed by the Internet2 Middleware Initiative. It is designed to allow collaborative organizations to flourish, using key collaboration tools in a secure and effective framework. The intent is to externalize identity management services, so that authentication and authorization of group members are handled in a single, efficient process that feeds into the various collaborative applications.

http://middleware.internet2.edu/co

Goals of eid (Export Import Directory Tool)

Metadirectory
Flexible and easy definition of data models
ETL (Extract, Transform and Load) tools for simplified conection to Source Systems
Pluggable algorithms for
- Unification for data coming from various sources
- Record deduplication
Flexible export to LDAP
Group management

https://spaces.internet2.edu/download/attachments/4033006/Carvalho-EID-CAMP-2009.ppt?version=1
http://sourceforge.net/projects/eid

Comparison of Use Cases

Use Case	OpenRegistry	KIM	OpenMetaDir	Grouper	OpenLDAP	COmanage
Create canonical record of person at institution
Reconcile heterogenous System of Record (SOR) records for a person
Assign unique institution wide identifiers across heterogenous SORs
Manage user groups and roles
Answer application specific permission questions (ie: real time answers to questions like "can person X spend $y from account z?")
Generate person specific attributes from multiple source records
Provision downstream systems and applications (LDAP, email, etc)
Manage user credentials
Provide audit facilties (who had access to what when?)

Supported (in design)
Could be done, but not primary purpose
Not Supported
Unknown

How KIM and OpenRegistry Relate

From the standpoint of KIM as a set of identity API calls in support of applications such as KFS via Rice*, and OpenRegistry as a standalone IDMS, OpenRegistry can treat KIM (really KFS and Kuali Student) as an authoritative System of Record (SOR), ie: a system that provides source data into OpenRegistry for downstream consumption. In much the same way that Banner, PeopleSoft, or Oracle SIS/HRMS can be loosely (nightly batch extracts) or tightly (real time calls) tied to OpenRegistry, KIM/KFS/KS can be tied as well. OpenRegistry serves as a "hub" handling data from multiple SORs - including KIM/KFS/KS - to multiple provisioned systems.

*From a conversation with Eric Westfall, KIM is a set of APIs for principals, groups, permissions, and roles, and comes with reference implementations that could be replaced by existing institutional infrastructure, such as LDAP and Grouper.

Browser not supported