This documentation provides information and instructions relating to migrating an application using InCommon from Shibboleth to Entra ID for authentication.  The intended audience is application owners.

First, what is the InCommon Federation?

The InCommon Federation is an example of a multi-lateral SSO federation; meaning that Identity Providers (like NC State) and Service Providers (some examples: Zoom, TopHat, Slate, MathWorks, Orcid, NIH, etc) join, creating a mesh of services and identity sources to be able to simplify how a user can get to and authenticate to a service.  The InCommon Federation is made up of more than 1,000 universities, research labs, and industry partners as well as over 5,000 separate applications.

Entra ID doesn't natively support the type of multi-lateral federation that the InCommon Federation makes use of.  To support this use case, NC State will be using the Cirrus Bridge middleware.  End users will never need to know that this middleware exists., Service Owners will likely need to know about it and reference it in the migration of their NC State applications that use InCommon.

When a user attempts to login to an application that is federated through InCommon, they will likely hit one of a couple specific patterns: a WAYF, a hardcoded IdP, or a combination of the two:

• A WAYF (Where are you from?) is a user interface pattern where you pick where you are trying to authenticate from.  This is usually a search box or a really long list where the end user chooses NC State University.
• A hardcoded IdP is usually associated with a specific provisioned url for the university in a cloud SaaS service.  So you'll have something like a ncsu.<vendor>.com or <vendor>.com/ncsu/ URL pattern that when you attempt to access the instance, it automatically redirects you to a specific NC State IdP.
• A combination of the two is often asking for an email address and then redirecting based on the domain. So if an end user enters <unityid>@ncsu.edu it would send you to a specific NC State IdP.

How does this impact migrating from Shibboleth to Entra ID?

In the WAYF UI pattern, the user will simply be presented with the full list of IdP's, which means that they will be able to use the (Production) Shibboleth IdP and the (Development) Cirrus Bridge IdP at the same time. This will continue to work up until we remove the Shibboleth IdP from the federation and rename the IdP's.  That will essentially be the "cut over" for an application using that UI pattern.

If you wish to test the Cirrus IdP prior to the "cut over" for applications that dynamically populate the WAYF the names of the NC State IdP's are:

• Shibboleth (old) - North Carolina State University
• Cirrus Bridge (new) - zDEVELOPMENT - North Carolina State University

For instances of a hardcoded IdP (either version), Service Owners will need to work with their vendor to switch which IdP is hardcoded.  Once that change is made with the vendor, that will be the "cut over" for that application.

The EntityID's for the NC State IdP's are:

• Shibboleth (old) - "urn:mace:incommon:ncsu.edu"
• Cirrus Bridge (new) - "https://sso.ncsu.edu/idp"

Providing that to the vendor should be enough information for them to switch which IdP they are using.

If a vendor has questions about the attributes being provided, please include a link to Attributes Provided by NC State's Entra ID WorkForce Tenant.

The goal is to remove the Shibboleth IdP from the federation once the last application that is using the hardcoded IdP pattern migrated.  This will be determined is by reviewing the sign in logs for the IdPs.