IAM Cloud Integration Standards & Guidelines

Introduction

The purpose of the following guidelines is to inform campus departments about the IAM-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

Identity Provider (IdP ) - The authentication and attribute provider. For The University of Texas at 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 EID holder.

Service Provider (SP) - The externally hosted service that is integrating authentication and authorization to its service based on the UT EID.

Sponsor - The department or organization that is sponsoring or purchasing the externally hosted 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.

Shibboleth - The particular implementation of a SAML Identity Provider that is used at UT Austin.

Provisioning and Deprovisioning - The process of how user accounts are created and deleted, archived or made inactive when no longer needed within the Service Provider.

Attributes - The data about the user that is connected to the UT EID such as name, email, major, department, etc.

Resourcing

1.     The Sponsor should consult the IAM Team early in their vendor selection process to help assess the Service Provider’s authentication and authorization capabilities.

2.     The Sponsor should develop an implementation plan that includes regular checkpoints with the IAM team.

3.     Roles and responsibilities of both the Sponsor and the Service Provider should be clearly understood and documented prior to the implementation and the ongoing sustainment of the service.

4.     The Sponsor should request that the Service Provider identify and provide a dedicated technical contact that is familiar with SAML integration.

Implementation

1.     If the service has already been separately implemented by multiple departments on campus, departments should consider migrating into a single campus-wide instance 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 Provider (IdP) is 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 person attributes 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 Identity Provider (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 Sponsor should review the Shibboleth documentation prior to the integration with a Service Provider, to understand the features and limitations of the university’s SAML IdP service. For example, single log out (SLO) is not a feature of the SAML IdP.

6.     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.

7.     The Sponsor should confirm that the Service Provider is able to perform automatic, dynamic SAML metadata refreshes.

8.     The Sponsor should understand and document how users will be provisioned and deprovisioned.

9.     If possible, the Service Provider should use UT EID (or the eduPersonPrincipalName 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 Sponsor should consult with the IAM team for implementation guidance.

10.  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.

11.  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.

User Experience

1.     The sponsor should determine who should provide ongoing user support for the service (the Service Provider, the sponsoring department, or some other group). The Sponsor should create an informational page that informs users of where and how to get support for the service.

2.     The service should provide a landing page that is not protected by SAML for users to bookmark that 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).