When integrating your new application with IAMIAM Identity and Access Management (IAM) is a set of policies, processes, and technologies designed to ensure that the right individuals (identities) have the right access to resources within an organization. IAM involves managing and securing digital identities, controlling access to systems and data, and maintaining the confidentiality, integrity, and availability of information. Services, you may have the option to receive one or more attributes as part of the integration.
We have a fairly comprehensive list of those attributes published in the TED Directory Schema but that might not help if you don’t fully understand the attributes or what you are getting.
Identifiers
This document presumes that you have already read our Concepts page and are familiar with what an identifier is.
Identifiers Can Change
The most important thing to be aware of is that there are no truly immutable identifiers (unless the scope of the identifier is limited to your system). That is, once an identifier is used by an external system
That is, once you leave the scope of a system, you cannot rely upon an identifier to never change. For example:
- Your Social Security Number (SSN) can change under limited circumstances .
- Your driver’s license number can change. For example, if you moved to a different state or country.
- Your U.S. Passport Number changes every time you renew it.
Likewise, your UT EID can change.
Because the eduPersonPrincipalName and the Institutional Identifier are based on your UT EIDUT EID The University of Texas Electronic Identity (UT EID or EID) is the public records identifier for principals at the university. See our Concepts page for more information., if your UT EID changes then your eduPersonPrincipalName and Institutional Identifier will change, as well.
If you are developing your own application, it helps to keep this in mind. It’s entirely reasonable to have a separate, local, unique identifier which is scoped to your application. You might also then develop your system to be able to assign one or many identifiers to that local identifier.
If you are obtaining a third-party application, it’s a good idea to ask the vendor how they handle these sorts of situations. Importantly, if an identifier changes, what is the process for getting a person’s data re-associated with them? Who will be responsible for that process?
Email Address as Identifier
Many cloud-based services elect to use the email address as the primary identifier. The challenges in doing so can be illustrated in the life cycle below:
In this example:
- Susie enters the University directly out of high school and chooses the example email address
susie@utexas.edu. - At some point during her time at the University, she receives an account on a cloud application using her
susie@utexas.eduemail address. - As she prepares to apply for jobs post-graduation, Susie decides to change her email address from
susie@utexas.eduto the more professionalsusan@utexas.edu. How will the cloud application handle this change? - After Susan graduates, she is no longer eligible for her University email account and
susan@utexas.eduis decommissioned. How will the cloud application handle this change? - Another student at the University decides to claim
susan@utexas.edu. How will the cloud application handle this change?
As demonstrated above, the use of the email address as a primary identifier presents a number of challenges, especially if the cloud application is designed in a way such that the primary identifier cannot be changed.
The above scenario is mitigated by the University through use of the Institutional Identifier (IIDIID The Institutional Identifier (IID) (format: <eid>@eid.utexas.edu) is designed for use with cloud-based services whose usernames are e-mail addresses. When used as an email address, will forward to the user’s email address on record. Guest-class EIDs do NOT have IIDs unless they have been granted a special entitlement.). This identifier takes the form <eid>@eid.utexas.edu, forwarding email to the email address on record. While the UT EID (and, therefore, the IID) is more stable than the email address, its mutability (as mentioned above) still presents some challenges.
Names
There are many name attributes available.
Whenever possible, we recommend that you use the Display Name. This will always be populated with the individual’s preferred or chosen name.
You should not request the legal name attributes unless you have a legitimate business need. For example, The University of Texas Police Department and the ID Center would have legitimate business needs.
Names vs. Codes
If you’ve been at the University (or any university) for a sufficient length of time, you will know that reorganizations, rebranding, and renaming happens all of the time.
So what happens when your application is looking for “Department ABC” and they change their name to “Department XYZ?” The answer is that your customers will no longer be able to get into your application.
The IAM Team always recommends that you key off of corresponding codes instead of names since those tend to be longer-lived (though not necessarily permanent).
| Instead of… | Use this! |
|---|---|
utexasEduPersonJobClassCategory | utexasEduPersonJobClassCategoryCode |
utexasEduPersonMajor | utexasEduPersonMajorCode |
utexasEduPersonMajorDept | utexasEduPersonMajorDeptCode |
utexasEduPersonOrgUnitName | utexasEduPersonOrgUnitCode |
utexasEduPersonSchool | utexasEduPersonSchoolCodeor utexasEduPersonSchoolMajorCode |
It’s perfectly okay (and preferred) to take and display the name attribute in real-time, but if you are making decisions in your application you should consider using the code instead.
With one of our University departments as an example:
| Year | utexasEduPersonOrgUnitCode | utexasEduPersonOrgUnitName |
|---|---|---|
| 2004 | VPEC | Office of the Vice President for Employee and Campus Services |
| 2009 | VPEC | Office of the Vice President for University Operations |
| 2017 | VPEC | Operations |
| 2018 | VPEC | Financial and Administrative Services |
As demonstrated above, while the utexasEduPersonOrgUnitCode remains stable over the years, the utexasEduPersonOrgUnitName changes on a somewhat-regular basis.
Multi-Value Attributes
While reviewing the TED Directory Schema, you many notice that some attributes are single-valued and some attributes are multi-valued. This can be an important distinction!
Let us use the utexasEduPersonAffiliation attribute as an example.
- This attribute is not listed as required, so there may be zero values for this attribute!
- A community member who only uses the UT Libraries will have the
library-patronaffiliationAffiliation An affiliation is an attribute which reflects, at a high level, how an individual is related to the university. At any point in time, an individual may have no defined relationship, one defined relationship, or many defined relationships with the university. For example, and individual may be a current student, a future faculty member, a former employee, or all three.. If that is the only way in which that individual interacts with the University, then they will only have one value for this affiliation. - A student employee can be expected to have, at the least, a
student-currentand anemployee-currentaffiliation. They will probably also have aprospective-studentaffiliation. If they had participated in the OnRamps program while they were in high school, they might also have anonramps-student-formeraffiliation. In this example, the individual has many values.
An important thing to know about multi-value attributes is that they will be provided to you in no particular order, unless you sort it on your own. So, for the example student employee above, you will receive all four attribute values, but not necessarily in any consistent order.
If the order in which the values of multi-valued attributes is returned to you is important, you will need to make allowances for this in your application.
More Information
For more information regarding the UT EID and the basic information associate with a UT EID, please review:
