Entra ID Authentication Profiles
Each unique authentication profile is equivalent to its own Entra ID Enterprise Application.
Your Cirrus Implementation Lead will work with you to develop additional profiles & provide support for configuration.
An authentication profile includes a NameID format and value, set of attributes, and signing & encryption settings. A typical implementation will include a default profile for SAML and one for CAS. Additional profiles can be created if required.
Creating An Enterprise Application
Sign into the Entra ID portal.
Choose “Enterprise Applications” in the menu, then click “New Application”.
Search for “Cirrus Identity”.
Select the “Cirrus Identity Bridge for Microsoft Entra ID” gallery app.
Choose a name for your application.
For the default application, we recommend “Cirrus Default Bridge”.
For other InCommon applications, select a name that fits your naming conventions and the purpose of the application.
Application Visibility and Assignment
By default, Cirrus recommends that you set Assignment Required and Application Visibility to "No".
However, if your institution’s security policies require assignment, then setting Assignment Required to "Yes" and add the appropriate settings under "Users and Groups".
Set Up Single Sign-On
Select ‘Single Sign-On’ from the left menu.
Choose the SAML option.
Edit the Basic SAML Configuration.
Enter the Entity ID & Reply URL (ACS URL) provided by the Implementation Lead.
For additional authentication profiles (Enterprise Applications), use the Entity IDs for those applications, but use the ACS URL from the default profile.
Configure Attribute Release
Next, the attributes will be configured. Entra ID calls them claims. Entra ID also allows you to perform transformations to your attributes.
NameID Format & Value
The default NameID Format is transient, which means the NameID value is generated as a unique value for this transaction.
Entra ID does not support transient NameIDs, so you will need to add a claim with a Cirrus rule with the following values to instruct the Bridge to send a transient NameID.
- Name:
cirrus.nameIdFormat - Value:
urn:oasis:names:tc:SAML:2.0:nameid-format:transient
Default Profile: Research & Scholarship Attributes
To meet the REFEDS research & scholarship entity category requirements used by InCommon, you must configure the following attributes. We typically recommend you configure them on the default application.
| Attribute (friendlyName) | OID | Equivalent Entra ID Attribute |
|---|---|---|
| Surname (sn) | urn:oid:2.5.4.4 | user.surname |
| Given Name (givenName) | urn:oid:2.5.4.42 | user.givenname |
| Display Name (displayName) | urn:oid:2.16.840.1.113730.3.1.241 | user.displayname |
| Email address (mail) | urn:oid:0.9.2342.19200300.100.1.3 | user.mail |
| eduPersonPrincipalName | urn:oid:1.3.6.1.4.1.5923.1.1.1.6 | user.userprincipalname |
Asserting MFA
If you are using Entra ID MFA, then the Cirrus Bridge will automatically assert the REFEDS MFA authncontext to downstream service providers.
If you are using another source for MFA, such as Duo, you may need to manually assert MFA since Entra ID may not signal to the Bridge that MFA was performed for users.
In this case, add an additional attribute with the following name and value,
- Name:
cirrus.rule.authnContext - Value:
https://refeds.org/profile/mfa
By adding this attribute, you are asserting that all users that use this application have performed MFA.
Assertion Settings
Entra ID signs both the SAML response & assertion. Some applications may only want one or the other signed.
Our recommendation for the default application is to only sign the response. This configuration will match Shibboleth’s default behavior.
Encryption (Optional)
If you are migrating from Shibboleth, you likely have a default policy to encrypt all assertions.
To enable this, navigate to the “Token Encryption” menu, import the certificate for the Cirrus Bridge, and then activate the certificate. It can take several minutes for Entra ID to start encrypting assertions.
Entra ID Specific Guidance
When retiring a legacy Shibboleth server, you might choose to do some application "housecleaning". For example, reviewing usage logs often uncovers applications that are no longer in use.
Moving SAML applications from Shibboleth to the Cirrus Bridge provides an opportunity to simplify your environment.
Enterprise Application Configuration Tip
In Entra ID, a single Enterprise Application can support multiple SAML applications when they have similar requirements. For example, some customers configure the default Authentication Profile (mentioned above) with commonly used, non-sensitive directory attributes and use it for SSO to many downstream applications. An application can successfully authenticate as long as the assertion contains the attributes it requires; attributes it doesn't need are typically ignored.
You don't necessarily need an Entra ID Enterprise Application for every downstream application. Where applications have the same requirements, they can share an Enterprise Application.
Create a separate Enterprise Application when an application has a requirement that is different from the shared configuration, such as:
- Attributes: It requires attributes that should not be released to other applications, particularly sensitive attributes.
- NameID: It requires a different NameID format.
- Assertion Security: It requires encrypted assertions or a different signing configuration.
- User Access: It should only be available to specific users or groups.
- MFA: It has different MFA requirements.
For example, your default Cirrus Bridge Enterprise Application might support dozens of SAML applications that use the same non-sensitive attributes, NameID, and signing configuration. A separate Enterprise Application could support a smaller group of applications that require a sensitive attribute, without making that attribute available to all of the other applications.