An Identity Registry is a system which registers and maintains information about entities of interest to the organization operating the registry, and to make this information available to other systems. This definition comes from the Identity Registries Team in the now-retired CIFER (Community Identity Framework for Education and Research) group organized by Internet2.
The concept of an Identity Registry is not new, though the language describing it tends to be unique to Higher Education.
Identity Registries and Systems of Record
The identity registry has a different logical function than a System of Record (SOR), though in situations where only one system of record existing, the SOR functions as the Registry.
A System of Record is the authoritative source for data about a specific piece of information, such as the fact that a person is a valid student, faculty, or staff member.
An Identity Registry, however, focuses on the information needed to support authentication and authorization decisions. The SOR for HR will have social security numbers, banking information, home addresses, etc. The Identity Registry will have names, eduPerson and other identifiers, group membership information, and so on. The point of overlap for all systems will be a common identifier for each individual user, human or otherwise, in the ecosystem.
What is an Identity Registry used for?
So what might a campus use the Identity Registry for? The Identity Registry can act as the attribute authority for the campus Single Sign-On (SSO) system, providing authentication and authorization controls to web and cloud services. The Identity Registry also feeds the federated identity system, that system which builds off the SSO system to support the IAM needs of your users when they are using resources at other organizations.
A “Registry” can be implemented using a variety of tools, such as a database, LDAP instance, Master Data Management tool, Virtual Directory and more. Ideally the tool will have good support for maintaining data synchronization with upstream (SOR) and downstream (applications) sources. The Registry should also scale to support high volumes of real-time requests for attribute release during authentication events and data-rich loading and reconciliation events.
In some cases, campuses use the Identity Registry to support the addition of users that do not exist directly in any given SOR, such as incoming students and job applicants. This can be very useful in maintaining authorization for users as they migrate from “affiliate” or “guest” status into one of the core systems of record for a campus. By maintaining the same organization-level UID for those users, basic authentication attributes don’t change as users migrate from one SOR to another. Applications can update authorizations based on other data that changes in eduPerson affiliation mappings, group memberships, etc.
Having a dedicated registry for the digital identities that belong on your campus, but which is separate from the highly sensitive information that is kept in an SOR, is one of several items that should be in your campus security profile.
Learn more about Identity Registries
- “Identity Registry Environments,” University of Washington https://wiki.cac.washington.edu/display/infra/Identity+Registry+Environments
- “LDAP Services,” Harvard University, https://iam.harvard.edu/get-started/ldap