Situation
Many service providers (SPs) rely on externalized, attribute based access control (ABAC) to manage what end users can do. In research and academia, it is very common for an individual to have multiple relationships with an institution at the same time – any combination of student, employee, and alumni. A common way to reflect this for access control is to use the eduPerson ( https://refeds.org/eduperson) attribute called eduPersonScopedAffiliation.
Background
The eduPersonScopedAffiliation is a multivalued attribute that consists of two parts. The first part is from a fixed vocabulary of defined affiliations:
- “member”
- “student”
- “faculty”
- “staff”
- “employee”
- “alum”
- “affiliate”
- “library-walk-in”
NOTE - The assertion of “student”, “faculty”, “staff”, or “employee” implies the end user is also a “member” of the organization and should also include a “member” value per the eduPerson specification.
For more details, see:
https://wiki.refeds.org/display/STAN/eduPerson+2021-11#eduPerson202111-eduPersonAffiliation
The second part consists of a scope for the affiliation represented by a domain (such as “example.edu”) that is authorized by a given identity provider (IdP).
When combined, an individual scoped affiliation will look something like “member@example.edu”.
While the end goal is to have a multi-valued attribute that shows how the end user is affiliated with the organization, additional values beyond the defined vocabulary should not be used. Doing so introduces confusion outside of the organization, and can cause SP errors. If an organization is tempted to create other affiliations, using eduPersonEntitlement is recommended (https://wiki.refeds.org/display/STAN/eduPerson+2021-11#eduPerson202111-eduPersonEntitlement).
Example
Consider a university – Huge U (hugeu.edu) with a distinct, but related, law school (law.hugeu.edu). While Huge U runs a unified IdP for the organization, the law school tends to operate very independently utilizing its own services. Alice is an alum of Huge U, and is on the faculty of the engineering department. Alice is also studying patent law at the law school.
In most cases, the independence of the law school will not be reflected in the eduPersonScopedAffiliation and you would expect something like the following for Alice:
member@hugeu.edu
student@hugeu.edu
faculty@hugeu.edu
alum@hugeu.edu
Unless it is key to differentiate between faculty, staff, and student employees -- some organizations simplify the vocabulary of [“student”, “employee”, “member”]. In other cases, organizations will just assert "member" until there is a need, or SP requirement, to provide more granularity.
If the law school operates independently, it is possible to see eduPersonScopedAffiliation asserted as the following for Alice:
member@law.hugeu.edu
student@law.hugeu.edu
member@hugeu.edu
faculty@hugeu.edu
alum@hugeu.edu
This would represent an IdP that asserts multiple scopes and also represents a much more complex access environment. This also represents a scenario where there is a system of organizations with a centralized identity management infrastructure.
Key takeaways
The key takeaways for eduPersonScopedAffilation are:
- SPs use eduPersonScopedAffilation to authorize access
- Do not use values other than defined vocabulary
- Asserting “student”, “faculty”, “staff”, or “employee” should have an associated “member” value
- Users can have multiple, simultaneous affiliations
- When in doubt, keep it simple
About this series
“Mark’s Assertions” is a series of articles about common challenges with implementing access management in Higher Education. The articles attempt to provide practical advice based on Mark Rank’s 20+ years supporting IT services – a decade of which focused almost exclusively on identity and access management deployments.
Mark Rank is the Director of Product for Cirrus Identity, and a member of the InCommon community.
The advice provided comes from observation and field experience working on diverse identity and access management deployments. The guidance may not be appropriate for all organizations or use cases.