Overview of UT Austin
The University of Texas at Austin (UT Austin) is a large institution with:
- Approximately 53,000 students
- 4,000 faculty
- 15,000 staff
Campus Service Units (CSUsCSU College, School, or Unit) operate in a decentralized manner, with many having their own budgets and decision-making authority. Centralized IT services are available through Enterprise Technology, but CSUs may choose to work independently.
As a vendor, you may interact with various specialized teams, including the 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. Team (also referred to as the “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. Team”). The IAM Team is part of Enterprise Technology and serves as an implementation partner for identity and access management services.
Nomenclature
Please refer to the University as:
- The University of Texas at Austin
- UT Austin
- UT
Avoid terms like “The University of Texas,” “UTA,” “U of T,” or “TU.” Misusing these terms may indicate a lack of familiarity with the University.
Identity at UT Austin
Identity Management
The IAM Team manages identities using custom systems and third-party software, combining data from authoritative Systems of Record (SORs) into unified identity records. For example, a student employee’s data from the registrar and human resources is combined into a single record.
Directory Services
UT Austin maintains centralized directory services, including:
- Austin Active Directory (Austin ADAD Active Directory (AD) is a directory service from Microsoft which implements Internet standard directory and naming protocols. See Austin Active Directory (Austin AD) in the service catalog for the University’s local implementation.)
- uTexas Enterprise Directory (TEDTED The uTexas Enterprise Directory (TED) is the University’s enterprise directory. See uTexas Enterprise Directory (TED) in the service catalog for more information.) (an LDAPv3LDAP Lightweight Directory Access Protocol (LDAP) is a set of protocols for accessing information directories based on the standards contained within the X.500 standard, but is significantly simpler.-based service)
The IAM Team ensures identity data in these directories is accurate and up-to-date.
AuthenticationAuthentication Authentication is the act of determining that a person is who they claim to be. For more information, see our Concepts page. Services
The IAM Team manages authentication via Enterprise Authentication, using the Shibboleth IdPIdP An Identity Provider (IdP) is a software tool or service that offers user authentication as a service. The IdP manages the user's primary authentication credentials and issues assertions derived from those credentials. At UT Austin, the primary IdP used to authenticate the UT EID and EID Password is Enterprise Authentication, which is managed by the IAM Team. For more information, see our Concepts page. to support SAMLSAML Security Assertion Markup Language (SAML) is a standard, XML-based language for exchanging authentication and authorization data between identity providers and service providers. This standard is currently used by Enterprise Authentication (as well as hundreds of service providers that integrate with our identity provider). 2.0 and OIDCOIDC OpenID Connect 1.0 (OIDC) is an authentication layer built on OAuth 2.0 where the identity provider that runs the authorization server also holds the protected resource that the third-party application aims to access. 1.0. This reduces the risk for vendors by ensuring passwords are handled securely.
Common Points of Friction
Scope of User Directory
The University of Texas at Austin’s directory is significantly broader than a typical corporate environment. It includes not only employees but also students, alumni, retirees, affiliates, and other populations – each with distinct access needs, data governance rules, and identity lifecycles.
Critically, a single individual may hold more than one of these relationships simultaneously. A graduate student who also works as a teaching assistant, for example, carries both a student affiliationAffiliation 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. and an employee affiliation at the same time. Each relationship may grant different access rights, and each has its own start date, end date, and governing policy. Applications that assume a one-to-one relationship between a person and a role will not behave correctly in this environment.
Recommendation: Design authorizationAuthorization Authorization refers to the act of determining whether an authenticated user is allowed to access a specific resource or take a specific action. For more information, see our Concepts page. rules around a user’s specific affiliation or role — not their broad membership in the directory. Attribute-Based Access Control (ABACABAC Attribute-Based Access Control (ABAC) is a mechanism for managing of user access to information systems based on values of user attributes. Attribute-Based Access Control (ABAC) evaluates the access dynamically, using an algorithm that takes “attributes” as an input, and outputs access decision (allow/deny). The attributes are usually user attributes from the user profile, supplemented with context attributes, such as time of access and user’s current location.), which evaluates access dynamically based on user attributes such as affiliation, department, and entitlements, is strongly preferred over simpler models that treat all directory members as equivalent.
Scope of Identifiers
User identifiers at UT Austin behave differently than those in most enterprise environments. Vendors should be aware of the following before designing login or user-matching logic:
- The UT Electronic Identity (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.) is the University’s official identifier. Though not immutable, it is stable, unique to each individual, and persists across role changes, email changes, and departures. It is the most reliable key for identifying a user across UT systems.
- Email addresses are not stable identifiers. UT Austin users may choose between Microsoft 365 and Gmail for their institutional email. Addresses may change, and some user populations – such as affiliates or sponsored guests – may not be assigned a University email address at all.
- Accounts may remain active after a user’s departure. Alumni accounts, for example, may persist indefinitely. An active account does not indicate a current affiliation with the University.
Recommendation: Use the UT EID as the primary user identifier wherever possible. Do not rely on email address alone to identify, match, or authorize users. Implement authorization rules that verify a user’s current affiliation and entitlements at the time of access — not just their presence in the directory.
Identity Lifecycle Events Are Not Instantaneous
In a corporate environment, identity changes — a new hire, a termination, a role change — are typically discrete events that trigger immediate, predictable system updates. At UT Austin, identity lifecycle events are more gradual and more complex.
A student’s enrollment status may change mid-semester. A staff member may transition into a student role without fully leaving their employee role. A researcher may gain or lose access to sponsored systems based on grant activity that is tracked outside the University’s core HR and student information systems. In each case, the timing and sequencing of identity updates depends on multiple upstream authoritative sources that do not always change in lockstep.
Recommendation: Do not assume that a user’s attributes at the moment of account creation reflect their current state at the moment of access. Applications should re-evaluate a user’s affiliation and entitlements at each login, not cache authorization decisions from an earlier session.
Guest and Sponsored Populations Require Separate Consideration
Not every user who accesses a UT Austin application is a current student, faculty member, or staff member. A significant portion of the University’s identity population consists of individuals with limited or temporary affiliations — research collaborators from other institutions, prospective students, parents, contractors, continuing education participants, and sponsored guests.
These users may authenticate through different mechanisms than the general campus population. They may have reduced attribute sets, meaning that authorization logic relying on attributes common to employees or students may not function correctly for them. Their accounts may have explicit expiration dates, or may be governed by a sponsoring department rather than a central authoritative source.
Recommendation: Identify early in your integration design which user populations your application will serve. If your application will be accessed by guest or sponsored users, test your authorization logic explicitly against those populations. Do not assume that all authenticated users will carry the same attributes.
FERPAFERPA The Family Educational Rights and Privacy Act of 1974 (FERPA) is a federal law which pertains to the release of and access to educational records. Constrains How Student Data May Be Used
The Family Educational Rights and Privacy Act (FERPA) governs access to and disclosure of student educational records. For vendors integrating with UT Austin systems, FERPA has direct implications for how student identity data may be handled.
Student directory information – including name, enrollment status, and program of study – may be restricted at the individual student’s request. A student who has placed a restriction on their directory information must not have that information disclosed to unauthorized parties, including through application integrations that inadvertently expose it. Vendors who store, log, or transmit student attributes as part of their integration are subject to data handling obligations that must be addressed before deployment.
Recommendation: Do not store student identity attributes beyond what is necessary to operate your application. Consult the IAM Team and the University’s information security policies before logging, transmitting, or persisting any data received through a UT Austin authentication or directory integration.
Technical Information
Authentication
To use Single Sign-On (SSOSSO Single Sign-On (SSO) is a service which allows a user to use one set of credentials to access multiple applications.) with UT Austin’s primary identifier (UT EID), your application must:
- Meet the Vendor Requirements.
- Comply with the SAML Metadata Requirements (if applicable).
- Refer to the Authentication Integration Technical Details.
Identifiers
UT EIDsUT 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. are between 2-8 characters and may include letters, numbers, underscores, periods, and hyphens. Formats include:
- UT EID:
<eid> - eduPersonPrincipalName (ePPNePPN The eduPersonPrincipalName (ePPN) (format: <eid>@utexas.edu) is an attribute which is part of the eduPerson LDAP schema.):
<eid>@utexas.edu - 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. For more information, see our Public Documentation or our Internal Documentation [icon name="lock" prefix="fas"].):
<eid>@eid.utexas.edu
The Institutional Identifier (IID) is designed for use with cloud-based services whose usernames are email addresses. When used as an email address, the IID will forward to the user’s email address on record. Of note, we align with the segment of the industry which maintains that the email address is not an appropriate user identifier1234.
Authorization
Authorization rules must be configured by the Service Provider (SPSP A Service Provider (SP) is the server/system which hosts the resource. In this context, you (or your vendor) are configuring the SP that provides a service to your customers. Your SP will integrate with our IdP. For more information, see our Concepts page.) or Relying Party (RPRP A Relying Party (RP) is an application or website that outsources its user authentication function to an IdP.). The most common implementation at UT Austin is ABAC.
If your application lacks authorization controls, consider submitting a Request for Enhancement (RFE) to your engineering team and review the OWASP Authorization Cheat Sheet.
Identification
If needed or desired, the IAM Team provides the ability to integrate identity creation directly into your workflow. This involves our systems loading your XHTML 1.0 Transitional HTML template from a publicly-available URLURL A Uniform Resource Locator (URL) is a reference to a web resource that specifies its location on a computer network and a mechanism for retrieving it. A typical URL could have the form http://www.example.com/index.html, which indicates a protocol (http), a host name (www.example.com), and a file name (index.html). Also sometimes referred to as a web address. you manage, injecting our content into a div in your template, and serving the synthesized page from our hosts.
Upon completion, users can be redirected to a URL of your choice with relevant information included as a URL parameter: either the UT EID which was created, or the error message if it was not.
Please let us know if this service, known as the UT EID Self-Help Tool Custom UI, would benefit your engagement.
Affiliation Management
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.
In rare (but not unheard of) circumstances, you may be called upon to manage affiliations on behalf of your University customer. In that case, you’ll want to review our Vendors and Affiliations page for more information and background.
Advice for Vendors
Comply With Standards
UT Austin’s authentication services comply with industry standards, including:
- SAML 2.0 (OASIS Standard, 2005)
- OpenID Connect 1.0 (Published, 2014)
Don’t Assume Immutability
Identifiers like UT EIDs and email addresses may change. Ensure your application can handle such changes.
Don’t Make Unsolicited Offers
The IAM Team does not accept unsolicited offers for any product or service. For more information, please contact the University’s Purchasing Office .
Meet Requirements
- Vendors must comply with Texas Risk and Authorization Management Program (TX-RAMP) requirements.
- Data must adhere to FERPA , HIPAA , and ITAR regulations.
Reference Our Documentation
Bookmark the Concepts and Terminology pages for quick reference.
Work with your University Contacts
The IAM Team provides technical support but does not oversee business rules or processes. Engage with your University contact early to ensure a successful implementation.
Frequently Asked Questions
(Click for the answer.)
How can our product create identities at UT Austin?
UT Austin offers two methods for identity creation:
- A customizable web application.
- A REST APIAPI An Application Programming Interface (API) is a set of routines, protocols, and tools for building software applications. endpoint.
To create an identity, you must provide:
- Name and date of birth.
- Email address or phone number.
Accounts cannot authenticate until the user sets up a password that meets UT Austin’s requirements.
What is the retention policy for UT EIDs?
UT EIDs are never decommissioned. However, much of the associated data is removed from directories upon departure. Core attributes like name, date of birth, and email address are retained to support future re-engagement with the University.
Footnotes
- Eve, Martin Paul. “We Are Terrible at Online Identity Management (Or: Using Emails as an Identifier Was a Bad Move).” Martin Paul Eve, 26 July 2023, eve.gd/2023/07/26/we-are-terrible-at-online-identity-management-or-using-emails-as-an-identifier-was-a-bad-move/. Accessed 9 Oct. 2024. ↩︎
- NetworkRADIUS. “Email Addresses Are Primary User Identifiers?” NetworkRADIUS, 21 July 2023, www.networkradius.com/articles/2023/07/21/email-addresses.html. Accessed 9 Oct. 2024. ↩︎
- Tietz-Sokolsaya, Nicole. “Email Addresses Are Not Primary User Identities | Nicole@Web.” Technically a Blog, 29 May 2023, ntietz.com/blog/email-address-not-identifier/. Accessed 9 Oct. 2024. ↩︎
- Wu, Albert. “Why Is Email Address Not an Appropriate User Identifier?” InCommon Federation Library, InCommon, 9 Feb. 2021, spaces.at.internet2.edu/display/federation/why-is-email-not-an-appropriate-user-identifier. Accessed 9 Oct. 2024. ↩︎
