When considering the development or acquisition of a new software product, it’s important to answer some core identity management questions to help ensure that the selected product will integrate well with the university identity environment.
Account Management
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 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. 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 you handle identifier changes?
Many applications leverage a user’s email address as their identifier. When not implemented carefully, these applications don’t account for situations where a user’s email address may change or their email account may no longer be accessible. Assuming that an external identifier is immutable presents a risk of data loss. If your application will use an email address, a 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., or some other external identifier, consider how will it handle scenarios where the email address or UT EID changes.
AuthenticationAuthentication Authentication is the act of determining that a person is who they claim to be. For more information, see our Concepts page.
How will users authenticate?
You will need to start by knowing which authentication solutions are supported by your vendor/developer (e.g. 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)., OAuthOIDC OpenID Connect 1.0 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., OIDCOIDC OpenID Connect 1.0 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., 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.
How will you handle multi-factor authenticationMFA Authentication makes use of one or more factors of authentication: something you know (e.g., a password), something you have (e.g., your smartphone), or something you are (e.g., a fingerprint). Multi-Factor Authentication (MFA) makes use of two or more factors when authenticating you. For more information, see our Concepts page.?
The university requires your use of multi-factor authentication. The solutions provided by the IAM Team allow you to enforce two-factor authentication on your applications.
If you cannot use multi-factor authentication your request will need to be approved by the UT Information Security OfficeISO The Information Security Office (ISO) is the university’s information security team. (ISOISO The Information Security Office (ISO) is the university’s information security team.).
Provisioning
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 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.)? Or will an administrator need to manually authorize accounts?
Remember that authentication is not the same thing as 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..
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.
De-provisioning
As mentioned before, the University environment changes frequently. You will need to consider how accounts in your application are de-provisioned. There are two common events which might trigger de-provisioning.
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 de-provisioning 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 de-provisioning actions.
Authorization Reporting
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.
Other Useful Resources
- IAM Cloud Integration Standards & Guidelines
- 3rd Party Security Assessments Minimum Requirements
- Local and Cloud Services Decision Matrix
- Texas Risk and Authorization Management Program (TX-RAMP)
Previous: Identity Concepts
Next: Integration Process
