The requirements for service provider metadata for integrating with the Enterprise AuthenticationAuthentication Authentication is the act of determining that a person is who they claim to be. For more information, see our Concepts page. Service are below. The requirements provide a number of critical benefits including greatly reducing the time needed to configure the integration and allows service providers to be the owners of their own contact information.
| # | Category | Requirement | Notes | Priority |
|---|---|---|---|---|
| 1 | Authentication | The system shall have the ability to delegate authentication to external provider. | The system should use one of the externalized authentication options listed below: 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). v2.0 or 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. | Critical |
| 2 | Authentication | The system shall have the ability to request “step up” authentication from the University’s authentication system when user access requires multi-factor authentication, for example by requesting a specific authentication context in a SAML request. | UT System policy requires that system administrators or users who interact with sensitive data remotely must do so by either accessing the system using the VPN (which requires multi-factor authentication) or the system must enforce a second factor authentication itself (all access to cloud-based applications is considered remote). If multi-factor authentication is only required for certain users (e.g. administrators) or for certain functions, the system should request stepped up authentication from the University’s authentication system in those cases. | Important |
| 3 | Authentication | The system shall have the ability to refresh SAML metadata if SAML is used for authentication. | The ability to automatically and dynamically refresh SAML metadata is the preferred method since it will make integration easier for both parties. | Critical |
| 4 | Identity Administration | The system shall have the ability to use 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., UT 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., or ePPNePPN The eduPersonPrincipalName (ePPN) (format: <eid>@utexas.edu) is an attribute which is part of the eduPerson LDAP schema. as the primary identifier for a user account. | 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 the unique user identifier at the University. Institutional identifiers (IIDs) are based on 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., but are presented in the form of an email address. IIDs are available for Member and Affiliate class EIDs (current, future, and former students/faculty/staff as well as certain University affiliates). ePPN (eduPersonPrincipalName) is used to distinguish UT Austin accounts from accounts at other institutions (i.e. @utexas.edu). ePPN is not the same as an email address. | Critical |
| 5 | Identity Administration | The system shall have the ability to accept user attribute assertions provided by the University’s authentication system. | User attributes may include Name, User ID, etc. | Important |
| 6 | Identity Administration | The system shall have the ability to update user attributes based on attribute assertions from the University’s authentication system. | The ability to automatically update user attributes is the preferred method. For example, an account attribute change may consist of a name change. | Desired |
| 7 | Identity Administration | The system shall have the ability to prevent users from manually updating user attributes provided by the University’s authentication system. | This is imperative since allowing users to manually update their attributes in the system could lead to security issues. | Important |
| 8 | Identity Administration | The system shall have the ability to store and manage local accounts credentials in a secure manner if local administrator accounts are needed. | Some systems require local administrator accounts for initial system setup or administrative access in the event external authentication is down. | Critical |
| 9 | Identity Administration | The system shall have the ability to ensure that local account passwords comply with UT password policies. | The password requirements from the University can be found at http://security.utexas.edu/policies/irusp#standard15 | Critical |
| 10 | Identity Administration | The system shall have the ability to merge existing user accounts. | The sponsoring department must have a plan for handling user account merges. | Important |
| 11 | 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. | The system shall have the ability to control user authorizations separate and distinct from authentication. | Some systems expect a user to be unable to authenticate to the system if they are not authorized. This is an incorrect assumption and systems must have the capability to control which functions a user can access after they are authenticated. | Critical |
| 12 | Authorization | The system shall have the ability to perform authorization checks based on the user attributes provided by the University’s authentication system. | Some of the complex conditions of the University may include checking multiple user attributes to determine the appropriate authorization. | Important |
| 13 | Authorization | The system shall have the ability to use externally provided roles and groups to manage authorizations. | Using role- and group-based authorization minimizes the number of authorizations that must be managed at the user level. For example, the system could use group memberships or entitlements delivered via SAML assertions. | Desired |
| 14 | Authorization | The system shall have the ability to allow administrators to periodically review authorizations to ensure that they are still needed and appropriate. | The sponsoring department must have a plan for how authorizations will be managed for their user populations on a ongoing basis. Some systems use automatic authorization re-certification to help with the authorizations review. | Important |
| 15 | Authorization | The system shall have the ability to export authorization data for reporting. | Many systems do not have the capability to systematically ensure authorizations are accurate and appropriate, therefore the system needs to be able export authorization data for reporting and review. | Desired |
| 16 | Provisioning and Deprovisioning | The system shall have the ability to provision authorized users. | On-demand provisioning in which users are automatically provisioned the first time they access the system is the preferred method. If back-channel provisioning is required, the process for establishing accounts prior to authentication will need to be defined by the sponsoring department. | Critical |
| 17 | Provisioning and Deprovisioning | The system shall have the ability to deprovision users who no longer need or should have access. | Systems may use filters based on asserted attributes such as 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. (i.e. former-student) to block access. | Critical |
| 18 | Auditing & Logging | The system shall have the ability to maintain history of user account activity including all changes to attributes. | This may include the ability to export logs to a system such as Splunk, depending on the sensitivity of the system. | Important |
| 19 | Auditing & Logging | The system shall have the ability to log group or role membership changes for audit and reporting purposes. | This may include the ability to export logs to a system such as Splunk, depending on the sensitivity of the system. Group and role change logs should include group/role name, time period, group/role member, or user who made the group/role change. | Desired |
Go back to the Vendor Guide to IAM at UT.
