What is a System of Record?

In identity management, a System of Record is an authoritative source for data about user or other entity. At many higher education institutions, the System of Record is the starting point for creating a directory of users including students, staff, and other people associated with the institution.

In order to both provide and protect services for your users, you first have to know who your users are. You also need to be able to share that information in a way that third-parties such as cloud services, campus learning systems, or research collaboration applications will understand.  That information is generally found in one or more Systems of Record (SOR) within your organization.

Photo by Tobias Fischer on Unsplash

A System of Record is the authoritative source for data about a specific piece of information. The most standard approach is to have a system of record for all employees, with a start and end date for each user. In Higher Ed, systems of record will also track whether a person is a valid student, faculty, or staff member. 

Most organizations already have at least one directory of information that works for the roles and positions that you support. In Higher Ed, the environment is often more complex, with two systems of record: a student information system and an HR information system.  Where there are multiple SORs,  they can feed into a common repository of person data, such as a Registry, Master Data Management tool, or another directory or database.

Some of the most popular Systems of Record (SOR) in Higher Ed include Ellucian Banner, Oracle PeopleSoft, and Workday. Some campuses combine student and HR systems of record, others use different vendor solutions for each.

Using data from Systems of Record

Multiple Systems of Record may feed into a common data store:

To use the information in a system of record to support access control decisions, all organizations involved must have a common understanding of the information being shared. The best way to support that common understanding is to use clear, globally consistent terms to categorize your users. 

The eduPerson schema, a well-known data classification schema used globally by academic organizations, includes eight common descriptors: faculty, student, staff, alum, member, affiliate, employee, library-walk-in.

As you move to use the information in a central directory to establish access to third-party services, you need to make sure that your internal terminology matches what the third-party service expects. For example, does your definition of what constitutes “student” match the expectations of the service provider (application)?  Are part-time students allowed access to this application?

Another key issue is how attribute labels are mapped. Is your information in a directory that maps cleanly to a data schema like eduPerson, while your third-party expects information in an entirely different format?

Data Attribute mapping challenge example:

These common definitions can be used in contracts or any Terms of Use that you negotiate with suppliers.   With these basic descriptions in place, you can then work with service providers on a definition that matches their expectations of who can access services.  You can also work with services that will help translate these clear terms into different protocols if that’s what’s required by the third-party service provider.

Handling edge cases: affiliates, guests and persons of interest

But what about those individuals in your system of record that don’t fall neatly into one of the eight eduPerson categories described?  Or users who don’t really belong in any of the official systems of record? As with any organization, there are likely to be a series of edge-cases or more complex relationships that require finer-grained descriptions to allow you to control the level of access those individuals have to the services the organization provides. 

Examples of this in Higher Ed include visiting teaching staff from other organizations that are running a short course at your campus, staff on campus involved in industry partnerships or work that is commercial in its nature, legitimate long standing partnership organizations or overseas campuses and pre-university provisioning for students before they start their period of study, or staff that are not formally within their contract period. 

Most systems of record have some designation for these non-standard users, such as “affiliates” or “Persons of Interest”. Adding “affiliates” to systems of record ensures they are provisioned into the organization’s identity management system, but the overhead can be quite high. Staff from HR typically need to get involved, and then these “non-standard” users occupy a seat in the organization’s system of record and core identity management solution which can add to licensing costs.

In some cases, it makes sense to stand up a separate, lightweight system of record just for “guest” or “affiliate” users. An organization needs a way to collect basic person profile data for these users, and can then add them to the feed into the central person data store.

Add Guest SOR:

Regardless of how you add guest users, you will need to document these cases and agree on an approach with your third-party services and the appropriate organizational stakeholder representatives regarding whether the users in these categories should be classified as authorized users, or if you need to restrict access or negotiate additional licenses for additional authorized user groups.  

In conclusion

The IAM ecosystem requires the existence of at least one System of Record to serve as the source of data about authorized users of the campus network and other online services.

Additional reading on the concept of an SOR can be found here:

• “Higher Education - Key IAM Components and Requirements,” https://spaces.at.internet2.edu/display/iamtep/Higher+Education+-+Key+IAM+Components+and+Requirements 
• “Introduction to Identity on Campus,” NSRC, https://learn.nsrc.org/fedidm/tech
• Santosh Kudva, “The Difference Between System of Record and Source of Truth,” https://www.linkedin.com/pulse/difference-between-system-record-source-truth-santosh-kudva/