The U-M Okta | Application Integrations service offering provides centralized authentication, MFA, and access management capabilities for university services.
To use this service, you must meet the requirements defined in this document, including ownership, use of supported integration methods, alignment with standard patterns, and ongoing lifecycle and attestation responsibilities.
Applications that require faculty, staff, students, or other university affiliates to authenticate in order to use the service must use this service for authentication. These central capabilities are the standard mechanism for consistent access control, reduced risk, and institutional controls.
If an application does not use, or is unable to technically integrate with, central IAM capabilities and uses local accounts, the SP is still required to meet all applicable requirements of U‑M policy DS‑22. The SP is responsible , and accountable via audit, for implementing equivalent controls including access control, provisioning/deprovisioning, logging/auditing, reviews, and other DS‑22 requirements as applicable.
Roles and Ownership
Each application integration must have clearly defined ownership to ensure appropriate access control, security, and ongoing service management.
Owners
Application integrations must have two identified Owners. Owners must be U-M faculty or staff members accountable for services that rely on U-M identities for authentication and/or authorization.
The Owners must:
- Define who should have access and under what conditions
- Ensure the service is used appropriately
- Approve and oversee access and lifecycle processes
- Attest to the accuracy and validity of the integration
- Lead relationships with any third-party vendors supporting the service
- Configure and maintain the service-side components of integrations with Okta and IAM systems
Vendor and Third-Party Coordination
Owners must manage the integration and relationship with any third-party vendors supporting their service; ITS does not assume this responsibility.
Any interaction between IAM support teams and third parties outside of the University of Michigan must be facilitated and led by an Owner.
Supported Integration Methods and Patterns
Application integrations must use one of the supported integration methods provided through U-M Okta Application Integrations. These methods ensure security, consistency, and long-term maintainability across university services.
Supported integration methods include:
- OpenID Connect (OIDC)
- Security Assertion Markup Language (SAML)
- Okta Integration Network (OIN) applications
Service Owners and Technical Owners must select the appropriate supported method based on the capabilities of the service and guidance from IAM.
Requirements
- Integrations must be implemented using one of the supported methods listed above
- Integrations must follow IAM-defined standard patterns and configurations for the selected method
- Custom or non-standard integrations are not permitted unless an exception is approved by IAM
Exceptions
Services that cannot support a standard integration method must work with IAM and IA to define an approved exception. The Service Owner must:
- Document the technical limitation preventing use of a supported method
- Understand and accept associated risks
- Ensure appropriate compensating controls are implemented to meet all applicable requirements of U‑M policy DS‑22
Integrations that do not use a supported method and do not have an approved exception may be denied onboarding or subject to deactivation.
Access Management Responsibilities
IAM will provide tools, data signals, and standard integration patterns that support authorization and access management, including institutional roles, groups, identity updates, and provisioning automation.
The Owners must:
- Define access criteria, roles, and entitlements for the service
- Approve and oversee access processes, including exceptions and manual approval workflows
- Ensure access remains appropriate over time
- Define and maintain service-specific access rules
- Implement and maintain access controls within the service
- Configure integrations with Okta and IAM systems
- Support provisioning and deprovisioning processes
- Execute operational access changes
The Owners are accountable for ensuring that access controls and processes are functioning as intended, regardless of delegation.
The Owners are responsible for any access management processes that fall outside IAM-supported standard integration patterns and automation capabilities.
Integration Metadata and Annual Attestation
Each application integration must maintain required integration metadata.
The Owners must maintain accurate metadata for the integration and ensure the accuracy and completeness of this information.
At least annually, and upon material change, the Owners must attest that:
- The integration is active and still required
- Ownership and support contacts are accurate
- Authentication and authorization mappings (claims, groups, roles) are correct
- Provisioning and deprovisioning processes are functioning as intended
Integrations that are not attested to may be denied continued use of the service or subject to deactivation following notice to the Owners.
Account and Access Lifecycle Responsibilities
The Owners must ensure that account and access lifecycle processes are defined and operating effectively for the service.
This includes:
- Joiner: Appropriate initial access based on defined criteria
- Mover: Timely updates when affiliation or role changes
- Leaver: Timely removal or disablement of access
- Privileged access: Least privilege, controlled assignment, and periodic review
If lifecycle automation cannot be fully implemented using IAM-supported standards and tooling, the Owners must ensure that alternative processes are implemented and maintained to ensure provisioning and deprovisioning are completed accurately and on time.