The purpose of the following guidelines is to inform campus departments about the Identity and Access Management related functions that need to be addressed when planning the implementation of an externally hosted service (sometimes called a “cloud-based” service) and to help them understand the available tools, techniques, and best practices. These guidelines will help campus departments better plan and execute their cloud service implementations.
Terms to Know
Attributes - The data about the user that is connected to the UT EID such as name, email, major, department, etc.
eduPersonPrincipalName (EPPN) - Scoped username. It is used to distinguish UT Austin accounts from accounts at other institutions (i.e. <UT EID>@utexas.edu). EPPN is not the same as an email address.
Identity Provider (IdP) - The authentication and attribute provider. For UT Austin, the IAM Team runs the IdP that allows for externally hosted service providers to use UT EID authentication and to receive attributes about the UT EID holder.
Institutional Identifier (IID)- An attribute (utexasCloudID) used with cloud service providers. Similar to, but distinct from the EPPN, IID places the UT EID in the format of an email address (i.e. <UT EID>@eid.utexas.edu). Emails sent to an IID are routed to the user’s email address, if they have one on file. IIDs are available through Shibboleth for Member- and Affiliate-class EIDs, as well as Guest EIDs with a special entitlement code.
Provisioning and Deprovisioning - The process of how user accounts are created, deleted, archived or made inactive when no longer needed within the service provider.
Security Assertion Markup Language (SAML) - SAML is an XML-based open standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. UT Austin uses the SAML 2 standard to support the integration of externally hosted services with UT EID authentication.
SAML Metadata - The IdP and SP have their own metadata and the sharing of this metadata between the two parties is what makes a secure SAML transaction work. This metadata contains certificate and endpoint information about each party.
Service Provider (SP) - The externally hosted service that is integrating authentication and authorization to its service based on UT EID. A service provider can also refer to the organization providing a service that is integrating authentication and authorization to users at UT Austin.
Sponsor - The department or organization within UT Austin that is sponsoring or purchasing the application provided by the SP.
Shibboleth - An implementation of a SAML identity provider used at UT Austin.
UTLogin - The primary UT EID authentication system and the preferred implementation of a SAML identity provider at UT Austin. UTLogin also offers web policy agent (WPA) client interfaces.
UT EID- The unique electronic user identifier at UT Austin.
1. All IAM integration service accounts must have a sponsoring department and contacts. A manager in the sponsoring department will be required to sign the Acceptable Use Policy for this service.
2. Roles and responsibilities of both the sponsor and the service provider (SP) should be clearly understood and documented prior to the implementation and the ongoing sustainment of the service.
3. The sponsor should consult the IAM Team early in their vendor selection process to help assess the service provider’s authentication and authorization capabilities.
4. The sponsor should develop an implementation plan that includes regular checkpoints with the IAM Team.
5. The sponsor should request that the service provider identify and provide a dedicated technical contact that is familiar with SAML integration.
6. The sponsor should determine who should provide ongoing user support for the service (the service provider, the sponsoring department, or some other group).
1. The sponsor should consider migrating into a single campus-wide service instance, if the service has already been separately implemented by multiple departments on campus, to reduce ongoing maintenance costs.
2. The sponsor should confirm that the service provider has a robust and fully implemented SAML 2.0 capability.
3. The sponsor should understand the limitations of what data the UT Austin SAML identity providers (IdP) are able to provide to the service provider. The data source for user attributes that are released by the UT Austin IdP is the uTexas Enterprise Directory (TED). A list of personattributes for release can be found in the TED Schema and Data Attributes documentation.
4. The sponsor should understand when and what data is transmitted from the UT Austin SAML IdP and how that impacts their business case. Attribute data is only provided during each successful authentication by the user. The sponsor may have to devise a separate process to provide data to the service provider if account data needs to be loaded before users can authenticate to the new service, or if the user account data needs to be updated outside of user authentication.
5. The service provider should use UT EID or the eduPersonPrincipalName (EPPN) attribute which is based on UT EID, not an email address, as the user identifier. If the service provider requires the use of an email address as the user identifier, the IID can be used instead.
6. The sponsor should determine if the service provider will need to authenticate non-person identities.
7. The sponsor should discuss contract obligations with the service provider that specifically protect UT Austin identity information to the level mandated by the applicable laws/regulations including FERPA, HIPAA, etc.
8. The sponsor should understand how the UT System Two Factor Authentication Mandate applies to the data being shared with service provider and determine if two-factor authentication is required.
9. The sponsor should understand and document how users will be provisioned and deprovisioned (i.e. on-demand, back-channel provisioning, etc.)
10. The sponsor should confirm that the service provider is able to perform automatic, dynamic SAML metadata refreshes.
11. The sponsor should confirm that the attributes should be automatically consumed and updated by the service provider on every assertion which will help keep all user attribute data stored in the service up-to-date and eliminate the need for staff to keep these updated. Due to potential security concerns, users should not be allowed to manually update these attributes.
12. The sponsor should verify that the service provider can handle authorization checks that take into consideration the complex conditions of UT Austin. For example, if the service provider needs to restrict access to a specific school or department, the service provider will need to be able to check multiple user attributes passed from the IdP to determine authorization.
13. The sponsor should develop a detailed test plan that includes testing authentication and authorization functions of the system. For example, if there will be multiple types of users in the system (e.g. students and administrators) the tests should include verifying that the system operates properly for each of these user types.
14. The sponsor should review the Shibboleth and UTLogin help pages prior to the integration with a service provider, to understand the features and limitations of the university’s SAML IdP services. For example, single log out (SLO) is not a feature of the SAML IdP.
- User sessions are not replicated between UTLogin and Shibboleth. A larger number of applications use UTLogin for authentication, so it is the recommended SAML IdP for a better Single Sign On (SSO) experience.
- Shibboleth implements more SAML features than UTLogin. For example, Shibboleth can generate some attributes that are not stored in TED, like IID, but UTLogin cannot.
- The IAM team will assess the needs of each individual product and determine whether a Shibboleth or UTLogin integration is appropriate.
1. The sponsor should create an informational page that informs users of where and how to get support for the service.
2. The service provider should have a landing page that is not protected by SAML for users to bookmark and has a link or button taking the user to the protected resource. Without a landing page, users may bookmark the IdP authentication page and will receive an error the next time they attempt to use the bookmarked page since the IdP will not know which service provider site to forward the user to. This landing page can be hosted anywhere (i.e. by the service provider or at UT Austin by the sponsor).