InfoSec
Shibboleth Attributes
One of the most valuable aspects of Shibboleth is the transmission of user attributes. The attributes are a named set of values which describe an authenticated user. When a user logs into your Service Provider (SP), the Shibboleth Identity Provider returns a set of attributes to the SP which can be used by the application for authorization decisions.
Following is a list of attributes and definitions currently available through the University of Missouri Identity Provider (IdP). During the SP request process, permission will be considered for the appropriate release of additional attributes.
| Attribute Name | Definition | Source |
|---|---|---|
| *samAccountName Example: sts123 | SSO ID | Active Directory – LDAP |
| *emailAddress Example: sts123@umsystem.edu | University assigned email address. | Active Directory – LDAP |
| *displayName Example: Student, Sally | Global Address List display name. Note: This value will be obfuscated for students asserting FERPA. | Active Directory – LDAP |
| *sn Example: Student | Last name Note: This value will be obfuscated for students asserting FERPA. | Active Directory – LDAP via PeopleSoft HR/Stu. |
| *givenName Example: Sally | First name Note: This value will be obfuscated for students asserting FERPA. | Active Directory – LDAP via PeopleSoft HR/Stu. |
| cn | Common Name (First Name, Last Name) Note: This value will be obfuscated for students asserting FERPA. | Active Directory – LDAP |
| *department | University assigned employment department for staff or program department for students. | Active Directory – LDAP |
| *eduPersonPrincipalName Example: @missouri.edu, @umkc.edu, @umsl.edu, @umsystem.edu, @mst.edu, @umh.edu, @umac.umsystem.edu. | The Principal Name contains the user’s SSOID@domain.edu. Note: This is not an email address. | Active Directory – LDAP |
| eduPersonAffiliation Example: faculty, employee, member, student | Specifies the person’s relationship(s) to the university in broad categories with controlled vocabulary. Individuals may hold more than one eduPersonAffiliation. The only permissible values for this attribute are: faculty, student, staff, alum, member, affiliate, employee, library-walk-in. | PeopleSoft HR or Student via UMDW |
| eduPersonPrimaryAffiliation Example: faculty | Specifies the person’s PRIMARY relationship to the institution in broad categories with controlled vocabulary. | PeopleSoft HR or Student via UMDW |
| eduPersonScopedAffiliation Example: faculty@missouri.edu, employee@missouri.edu, member@missouri.edu, student@umkc.edu | The Scoped Affiliation is created by joining the affiliation and the campus of that affiliation (e.g., faculty@missouri.edu). | PeopleSoft HR or Student via UMDW |
| **eduPersonTargetedID | A persistent, opaque identifier used to identify a user to a service provider. This identifier is cryptographically strong and unique to each service provider to ensure that the identity of the end user cannot be determined from the value. | The attribute value is made up of an identifier, the identity provider, and the service provider. |
| employeeID | Student number or employee ID assigned in PeopleSoft. | SSO data on UMDW |
| *Attributes released by default to internal Shibboleth Service Providers **Attributes released by default to all Shibboleth Service Providers | ||
UM Common Definition
Faculty
Any University of Missouri Faculty member as defined by HR Job data that is in Active, On Leave or Paid Leave status, not a retiree.
Staff
Any University of Missouri Non-Faculty (staff) member as defined in HR job data that is in Active, On Leave or Paid Leave status, not a retiree. (Not to include student titles).
Employee
Any individual employed by the University of Missouri regardless of employee type that is in Active, On Leave or Paid Leave status and not a retiree. Includes student employees.
Student
Any University of Missouri student enrolled for at least one course in the current or a future semester.
Member
Emeriti (currently for COLUM only) Anyone with the following affiliation types: Faculty, Staff, Employee, and Student.
Alum
Not used at this time.
Affiliate
Not used at this time.
Library-walk-in
Not used at this time.
UM Common Definition
When only one affiliation type is listed in the eduPersonAffiliation attribute that affiliation type should be listed as the eduPersonPrimaryAffiliation. If more than one affiliation exists in eduPersonAffiliation the below set of rules establish primary.
Faculty
If eduPersonAffiliation includes faculty it should be listed as the Primary Affiliation superseding all other values.
Staff
If eduPersonAffiliation includes non-faculty it should be listed as the Primary Affiliation superseding all other values except Faculty. (This conflict should not occur when using ps_convert.ps_um_employees, if another table is used rules will need to be adjusted, likely based on FTE of each position.)
Employee
Employee should only be used if eduPersonAffiliation does not contain Faculty, Staff or Student but they are employed by the university and hold this affiliation in eduPersonAffiliation. Employee supersedes Alum, Member, Affiliate and Library-walk-in. (i.e. a Student Employee who is not enrolled).
Student
If eduPersonAffiliation includes student it takes precedence over all values except Faculty and Staff. Student employees who are enrolled should be listed with a primary value of student.
Member
Member should be used as Primary only if Faculty, Staff, Student, and Employee do not exist in eduPersonAffiliation. Member should supersede Alum, Affiliate, Library-walk-in.
Alum
(Not used at this time.) Use if no other eduPersonAffiliation value except library-walk-in. Alum will only supersede library-walk-in.
Affiliate
(Not used at this time.) Affiliate should be used only if Faculty, Staff, Student Employee, and Member does not exist in eduPersonAffiliation. Affiliate should supersede Alum and Library-walk-in.
Library-walk-in
(Not used at this time.) Use library-walk-in if it is the only value listed in eduPersonAffiliation. Every other affiliation will supersede library-walk-in