When considering the development or acquisition of a new software product, it’s important to understand some core identity management concepts to help ensure that the selected product will integrate well with the university identity environment.
- UT Electronic Identifier (UT EID) – The UT EID is an electronic username issued to all university constituents. It is between two and eight characters in length. EIDs are divided into three classes: Member (current students, faculty, staff, as well as official visitors), Affiliate (future and former students, faculty, and staff; extension studies participants; library patrons; university affiliates), and Guest (prospective students, prospective faculty, job applicants, donors, and unaffiliated UT EID holders).
- Institutional Identifier (IID) – The IID is a version of the UT EID that takes the form of an email address. For example, the IID for UT EID “xyz123” would be email@example.com. Guest-class EIDs do NOT have IIDs unless they have been granted a special entitlement. For more information, see https://ut.service-now.com/utss/KAhome.do?number=KB0011278 .
- UTLogin – The University’s enterprise web single sign-on (SSO) service. UTLogin is based on OpenAM, an open source access management platform, and supports authentication via web server integration using OpenAM Web Policy Agents (WPAs) as well as SAML2 integration.
- Shibboleth – An open source federated authentication system based on the SAML2 standard. The IAM team offers Shibboleth-based SAML2 integration in addition to SAML2 via UTLogin.
- SAML2 – Security Assertion Markup Language. An XML-based open standard for exchanging authentication and authorization information between identity providers and service providers.
- OAuth2 – An open standard for authorization that allows end users to access web sites or resources without sharing their access credentials with those services. Note: Support for OAuth2 is scheduled to be available in the first half of FY2016-2017.
Identity Management Concepts
- Authentication vs. Authorization – Authentication determines whether the user is who they claim to be. Authorization determines whether an authenticated user is allowed to access a specific resource or take a specific action. While these concepts are closely related, they are distinct.
- Accounts, Identifiers, and Identities – An account is the representation of a user within a particular system. An identifier is how a user is labeled. In a system that uses UT EID-based single sign-on, the user account will be accessed using the UT EID as an identifier. An identity is the collection of accounts and identifiers associated with a particular person (or sometimes a non-person entity). An identity can be associated with multiple accounts and identifiers. For example, you may have multiple email accounts but all of those accounts belong to one identity (you).
- Provisioning and Deprovisioning – The process of how user accounts are created when they are needed and how they are deleted, archived, or made inactive when no longer needed.
- Identity Lifecycle – Like the real-world entities they represent, identities have a lifecycle. Their connection to the University will change over time and the accounts and authorizations they have will also change accordingly. However, the identity itself does not go away. When a user leaves the University (e.g. graduation, separation) their identity persists and they will continue to be able to authenticate using their UT EID. This allows individuals to later come back and apply for jobs, request transcripts, etc. Systems must take into account the current status of a user in their authorization schemes and change account authorizations when that status changes. So, for example, if a student or employee leaves the university, the wireless network will note the change in affiliation and remove authorizations for wireless access.
Identity Management Questions to Consider
How are user accounts conceptualized in your application? Recall that there is a difference between an account, an identifier, and an identity. In short: User accounts are like keys, and the identity is the key ring which unifies them.
As an example, if you are running a UNIX service you may not be able to use an EID as the username due to namespace collisions. If you have multiple UNIX services, how would you link the accounts belonging to the same person across these different services? How would those user accounts then be linked back to an identity?
Not all accounts refer to people. While an account is most frequently understood as referencing a person, non-person entities may have need for an account. For example, the EID system supports service accounts that represent applications. You may need to consider if non-person accounts are appropriate for your application and, if so, how your application will handle these accounts (e.g. who has the right to make a request on behalf of a non-person account?).
How will users authenticate? The IAM Team provides several solutions for EID-based authentication. You will need to start by knowing which authentication solutions are supported by your vendor/developer (e.g. OpenAM WPA, SAML, etc.). If EID-based authentication is not possible or not appropriate, you will need to consider how user accounts will be provisioned and managed over time, how they will be associated with the identity responsible for the actions taken with the account, and how authentication to the accounts will be managed.
Will your application require multiple factors of authentication? Some applications allow access to or
data that is either confidential or critical to university operations. You will want to review the Identity Assurance Framework to determine if multifactor authentication is appropriate for your application. If so, you will need to consider whether multifactor authentication will be required for all access to your application, or if multifactor authentication can be limited to certain contexts such as accessing specific sections of the application or performing specific actions.
How are user accounts going to be provisioned? Especially with vendor-provided applications, you will need to consider how accounts are created in your application. For example, will these accounts be automatically created for a user upon their initial login attempt? Or will an administrator need to set up the account prior to the user’s initial login attempt?
How are authorizations provisioned? Likewise, you need to consider that not all accounts in your application will be administrators. You will need to consider what the different authorizations in your application will be and how those authorizations will be granted. For example, will these authorizations be granted based on some attribute (e.g. a particular affiliation)? Or will an administrator need to manually authorize accounts?
Remember that authentication is not the same thing as authorization. As mentioned before, authentication is the process of verifying that a user is who they claim to be. This is typically done by having the user provide a token (e.g. password) that only they know. Authorization is the process of checking to see that the user is allowed to access a requested resource or take a specific action. For example, after authentication your application may learn that the user is a student. Based on that knowledge, your application may then make an authorization decision that the user is or isn’t allowed to access a specific part of the application.
How do authorizations work in your system? You must understand how your application handle authorizations. Can authorization decisions be made based on attributes obtained during the authentication process? Or are all authorizations created and stored internally in the application?
Authorizations need to be reviewed over time (for example, once a year). Who is the right person to review those authorizations and audit them? As you know, the University environment changes frequently. Students enroll and eventually graduate. Employees are hired, transferred, and terminated. Vendors are engaged and contracts end. As such, authorizations in your system will need to be reviewed on a regular basis. Depending on the sort of access your system provides, these reviews may need to occur as infrequently as once a year, or as often as once a week. You will also need to decide who in your area will be responsible for auditing those authorizations.
The service owner will need to take ownership of provisioning and authorization. While the IAM Team provides centralized solutions for authentication and providing directory information, you will be responsible for provisioning user accounts in your application and for making authorization decisions in your application.
As mentioned before, the University environment changes frequently. You will need to consider how accounts in your application are deprovisioned. There are two common events which might trigger deprovisioning.
Birthright changes occur when a University affiliation attribute of the user changes. For example, student graduation and employee termination are birthright changes that may need to trigger deprovisioning in your application.
Role changes occur when the identity’s affiliation itself doesn’t change but the nature of their work changes. For example, this will happen when an employee continues to be an employee, but their role within their department changes, or they transfer to a different department. Role changes are another common trigger for deprovisioning actions.
You must be able to report on authorizations. In order to ensure that users have the correct authorizations (and do not have authorizations which are inappropriate), your application will need to provide a view into what authorizations an user has. To provide a mass audit (i.e., to perform an annual review) your application should provide the ability to report on authorizations en masse.
Ideally, your application should be able to export authorization data into an external system. An external system would allow authorization data to be collected into a single location to allow for holistic reporting, auditing, and management for authorizations.