Campus is in the process of adopting Entra ID for Single Sign On (SSO).  This migration will not be a single massive migration of hundreds of services from one SSO option to another.  It will instead be hundreds of smaller, per service migrations.

This Knowledge Base article aims to help guide service owners in their migrations to Entra ID.  There are infrastructure changes in progress that influence whether a given application's needs can be met in Entra ID at this time.  Not all applications are able or recommended to be moved at this time.  Also note that this article uses a significant amount of terminology related to Identity and Access Management, please refer to the Identity and Access Management glossary reference if needed.

Below are a series of questions that help determine what path and timing makes the most sense for an arbitrary application to migrate to using Entra ID for SSO.  This is primarily focused on applications that use Unity accounts only today.

First it is good to outline our target default configuration for an Entra ID Enterprise Application (aka Service Provider):

• SSO Protocol: OIDC
• Authorization: Entra ID groups assigned to the Enterprise app
• Attributes: basic directory attributes, EduPerson attributes, and group memberships (limited to the groups used for authorization)
• Provisioning: SCIM (using the same groups used for authorization)

Not all applications will match this setup and that is ok.

Let's look at some of the IDM requirements that an application may have:

• Does the application make use of the InCommon multi-lateral federation?
• Does the application need the EduPerson set of attributes?
• Does the application need the REFEDS MFA profile?
• Does the application make use of Brickyard accounts in addition to Unity accounts?
• Does the application need any additional IDM attributes beyond basic directory attributes, the EduPerson attributes, or group memberships (for IDP authorization groups)?

If the answer to any of these questions is "Yes", then you currently will need to wait.  If you don't know what these questions mean, please refer to the Identity and Access Management glossary.

Each of these areas has work being done to provide support that is not completed as of November 1, 2025.  They will not all be completed at the same time, and some (like support for Brickyard accounts) may take a while.  So this helps inform the timing of a move.  If you need any of these and you have to setup SSO immediately, you should stick with Shibboleth for now.

If all of the above answers were "No" then you can start on your SSO Request for Entra ID, but you would be helpful to have some additional information to be able to complete the form.

Next let's talk about the technical implementation details of the application:

• Is the application currently using Shibboleth SSO, LDAP authentication, or is it new?
• Is the current SSO integration done at the infrastructure-level or app-level?
• Is it a custom, in-house written application or are you configuring a third-party application?
• If it is a third-party (whether SaaS or local install), does it have Entra ID (formerly known as Azure AD) support?
• Does it support OIDC, SAML, or both?

This information will help inform what type of integration will need to be implemented.

Application-level integrations, where the configuration of the SSO is within the application code itself, are generally the most flexible, and allow an application to move when it best aligns with the service needs.  It often does not matter what type of server it is installed on.  Most SaaS applications fall into this category and provide an abstraction to enable the configuration of one or even multiple SSO providers.  Many also provide native Entra ID (formerly Azure AD) integrations with OIDC that are simple to configure and use primarily only directory attributes (and sometimes group membership) information.

If the current implementation is done at the infrastructure level, such as a server with SSO configured across the board (like cPanel) or is a proxied environment (like the MyPack Portal) then it is important that all applications hosted on it on it move together or that it is broken up into multiple migrations, quite possibly involving building new infrastructure or moving to app-level integrations.

There are also third-party vendor applications that will only work with SAML.  That can be accommodated even though OIDC is the default.

Finally, let's talk about authorization and provisioning.  Entra ID provides features above what is available with Shibboleth to help provision accounts within an application and how to handle authorization:

• What type of account provisioning exists? Examples are: Just in Time (JIT), SCIM, scripted, spreadsheet import, or manually created accounts
• Does the application support SCIM provisioning?
• Does the application need to support non-Unity, non-Brickyard accounts (service accounts, .admin accounts, workshop accounts)?
• If the application is not meant to be available to all campus users, what are the criteria to determine the customer base? Examples are: SIS/HR data, per-user licensing, etc
• IDP or SP level authorization?

Entra ID was primarily designed with Identity Provider (IDP) level authorization and SCIM provisioning in mind (creates the account ahead of time), whereas Shibboleth was designed with Service Provider (SP) level authorization and Just in Time (JIT) provisioning (creates the account as you login).  This is a very fundamental difference in how units can manage their applications.  A common pattern in Shibboleth is one where all Unity accounts can authenticate to the application, but the application is responsible for determining what level of access a given user has.  This means that there may exist accounts with no permissions or roles assigned.  If those accounts aren't cleaned up, it is not only messy, but can increase the attack scope from compromised account or incur cost if its a per-user licensed service.  In Entra ID, the goal is to define who should be able to access the application externally (an example could be using Persona groups), and those groups are assigned to the Enterprise Application in Entra ID, where it prevents any account not within those allowed groups from attempting to access the application at all. You may then also configure SCIM to automatically provision and deprovision accounts based on that same group membership.  It is a cleaner and more secure setup, but it is also important to understand the implications of deprovisioning. When deprovisioning, is the application deleting resources, sending notifications, and other possible negative impacts if there are changes in upstream IDM data (dropping a course, changing a job class, etc).  This will help you understand your path.

While there are a large number of ways an Entra ID SSO integration can be configured, there are a couple broad categories:

• Most applications that are using the InCommon federation today also are using the EduPerson schema and SP-level authorization either with JIT provisioning based on affiliations or with scripted provisioning.  So once the prerequisites are met with those IDM data elements available in Entra ID, many of that class of applications can begin migrating.
• For instances of an infrastructure-level integration where a Linux servers running the Apache web server host a large number of applications, OIT is working on the procedure for swapping out the Shibboleth SP software with an Entra ID Apache module and rewriting the new Entra ID username to SHIB_UID, which is what most of the applications are looking for as a primary key for the user.  This procedure would again allow a set of applications to move in tandem.  This work is not completed yet, but will be linked to as a Knowledge Base article once available.
• Applications that make use of the Brickyard account system in addition to Unity accounts are dependent on certain changes related to the Guest/Affiliates project.  While it may be plausible to migrate from Shibboleth to Entra ID for Unity account authorization at this time, it would not be recommended to attempt to convert from SAML to OIDC or change the provisioning to SCIM until its possible to do so for both user populations, Unity and Brickyard.

This guide is intended to provide information that is needed to migrate to Entra ID and to give high-level background on what the migration may entail, but is not comprehensive.  As stated earlier, the migration from Shibboleth SSO to Entra ID is a long process where applications will migrate over a continuum, not all at once.  There are also opportunities to improve the current security and automation rather than just to "swap out a login page" as part of this process.