Campus is in the process of adopting Entra ID for Single Sign On (SSO) with a goal of finishing the migration by the end of the calendar year 2026. 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. 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 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):
Not all applications will match this setup and that is ok.
Let's look at some of the specific IDM requirements that an application may have:
If so, please refer to the InCommon federation with Entra and Cirrus Bridge article as many times the vendor simply needs to know that NC State is an InCommon member and the EntityID of our Identity Provider (IdP) in order to setup an integration with no configuration by OIT. The Cirrus Bridge IdP that NC State uses for Entra ID integration into the InCommon federation fully supports the REFEDS MFA profile.
If the answer to this question is "Yes" then you will need to consult with OIT about the migration path, as applications that make use of BOTH Unity and Brickyard accounts often are the most complex implementations.
If the answer to this last question was "No" then you can start on your SSO Request for Entra ID, but you will still likley need additional information to be able to complete the form.
Next let's talk about the technical implementation details of the application:
The answers to these questions and especially any documentation that can be provided 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 and it often does not matter what type of server it is hosted on. Most SaaS applications fall into this category and provide an abstraction to enable the configuration of one or even multiple SSO providers, though some require the vendor to do so rather than it being self-service. 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:
Entra ID was primarily designed with Identity Provider (IDP) level authorization and SCIM provisioning (where it creates the account ahead of time) in mind, whereas Shibboleth was designed with Service Provider (SP) level authorization and Just in Time (JIT) provisioning (creates the account as you login). This can be 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 external to the application (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 (or a more targeted group). 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 optimal path. Note that SSO configuration and SCIM provisioning can be done at two different times. So if you want to migrate the SSO from Shibboleth to Entra ID and then later deal with the provisioning, that is an option.
While there are a large number of ways an Entra ID SSO integration can be configured, there are a couple broad categories:
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.