/
Identity and Access Management Application Standard

Identity and Access Management Application Standard

1. Purpose

To ensure secure, scalable, and auditable access to university applications, this standard defines requirements for authentication, authorization, and account lifecycle management.

2. Scope

This standard applies to all applications developed, deployed, or directly or indirectly integrated within the university’s IT ecosystem that require user authentication and authorization, including on-premises, cloud-based, and hybrid systems.  Applications that are federated with the University are covered under the terms and conditions of the federation.

3. Definitions

Audience

An audience is a distinct group of users with specific access privileges and roles within an organization.  Audiences can include predefined groups such as Active University Members, Faculty/Staff, Students, Alumni, Emeriti, and Admitted individuals, as well as self-defined audience types incorporated into security groups for customized access control. This ensures secure and efficient identity management across various user populations.

Authentication

The process of verifying the identity of a user or system prior to granting access to resources.

Authorization

The process of granting access rights to authenticated users or systems based on defined permissions and roles.

Break glass Account

An account configured for emergency access in case of unforeseen outages. It should have a highly restricted password and be used only when necessary.

Central Identity Authority (Identity Provider, also known as IdP)

A trusted system that manages and verifies digital identities, centralizing authentication, authorization, which includes Microsoft Entra ID, Microsoft Active Directory, Kerberos, and 389/LDAP.

Non-interactive login

A login method used for service accounts that do not require user interaction. It must use secure authentication methods such as certificate-based or token-based authentication.

Federated Authentication

A method of authentication that allows users to log in using credentials via a Central Identity Authority.

SCIM (System for Cross-Domain Identity Management)

An open standard for managing user identities across multiple systems. It simplifies user provisioning, synchronization, and deprovisioning by automating identity data exchange using REST APIs and JSON-formatted data.

Service Accounts

A non-human identity used by software components to authenticate and interact with other systems.

Software Components

Applications, services, scripts, containers, or integrations between applications, services, scripts, and containers.

4. Central Identity Authority

All authentications (excluding the Break glass account) must be integrated with the university’s Central Identity Authority, in the following order of preference:

  • Microsoft Entra ID

  • Shibboleth

  • Microsoft Active Directory

  • 389/LDAP

5. Administrative Accounts

All administrative tasks, including initial configuration, must be performed using dedicated ITS centrally managed administrative accounts (a_). 

For applications with a limited number of licenses, ITS should minimally have one (1) dedicated licensed account to be used to perform administrative tasks.

6. Break glass Accounts

Break glass accounts must be configured for all applications as practicable. Any application using Single Sign-On (SSO) must have a break glass account to ensure access remains available in the event of unforeseen outages. These accounts should:

  • Meet all current password complexity rules and be a minimum of 32 characters long.

  • Be highly restricted and used only when necessary.

  • Be stored within the ITS Password Management Software with strict audit logging.

  • Be regularly reviewed to ensure proper use and compliance with security requirements.

  • Have the password rotated upon the departure of any user with access to such password.

  • Have the password rotated on at most a 36-month cycle.

7. Authentication Requirements

All applications must be configured to authenticate through the Central Identity Authority for all access levels, including, but not limited to, general user accounts, elevated user accounts, and administrator accounts.

7.1. Federated Authentication

Applications must support federated authentication using ITS-approved, industry-standard authentication protocols via a Central Identity Authority.

7.2. Service Accounts

Service accounts deployed for applications must comply with the service account standard.

8. Authorization

Authentication and authorization must be distinct processes. Users must authenticate to verify their identity, but authentication alone must not grant access permissions. Authorization must be separately controlled through Security Groups or other predefined mechanisms to ensure proper access management and prevent unintended privilege escalation.

Supported Authorization methods are:

  • SCIM

  • Security Groups and/or Attributes

    • Active Directory

    • 389

  • APIs: Programmatic provisioning via application integration.

  • Batch processes, including directory synchronization services: Automated bulk user provisioning from authoritative sources

All attempts must be made to avoid configuring authorization within the application using a manual process.  If a preferred option is not available, this configuration must be documented as a risk, particularly for administrative accounts or those with elevated access.

8.1. Access Reviews

All roles that grant administrative or elevated access are required to undergo an annual review to verify both the validity of the role and the accuracy of membership.

  • When possible, the review of privileged access should be automated. 

  • The method of the review must be documented.

  • All review findings must be documented and made available for the ITSM Service Team.

9. Lifecycle Management

9.1. Provisioning

Each application must clearly define its intended audience(s), access, and usability. The identified audience should align with a specific business need, supporting the application's purpose and functionality.

Provisioning Mechanisms:

  • SCIM

  • API

  • Batch Sync

  • Just-In-Time (JIT): On-demand, user is creation upon first access.

  • Please refer to the appendix for supporting provisioning technologies based on population.

9.2. Deprovisioning

Access should be removed within the application promptly when a user is no longer eligible, as defined by applicable business practices and/or policy.

10. Logging and Auditing

All authentications must be logged into central logging systems. Logs must be retained in accordance with university policy and reviewed for any anomalies.

11. Exceptions

Exceptions must be approved by ITS and reviewed annually.