Entra ID Applications: Advanced Configuration


Each Entra ID application may have specific needs that go beyond basic requirements. This page covers the most common advanced requirements. NOTE: This page is incomplete. Content is expected to be finished by 1/18/2022.

The default SAML claims provided by Entra ID are:
  • givenname
  • surname
  • emailaddress
  • name
If you need more claims, you'll need to add them. Entra ID sources all data for claims from Entra ID itself. This means the possible claims you can add are restricted to data which is present in UW Entra ID. Entra ID supports a wide variety of data transformations and conditions for claims issuance. https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-saml-claims-customization documents the basic process of adding claims, including transformation and condition capabilities. https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-enterprise-app-role-management covers application-specific role-based claims. This allows you to assign a role within your application based on claims data. If you have written your own application, see https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps for a more detailed description. If you have written your own application, then you have an Entra ID application object, and you may want more control over what claims are provided. You can use the application manifest (e.g. via the Application Registration interface) to do that. https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-optional-claims discusses this topic. If you need claims which rely on group membership data, we have strong recommendations. When configuring your "Group Claim", choose the 'Groups assigned to the application' option. This will ensure that users who are members of a lot of groups do not get an extremely large access token filled with groups which are not relevant to your application. To make this option work, you only need to assign the relevant groups to your application. See 'User Assignment'. If you can't assign all the relevant groups to your application, then use the Advanced options to filter which groups are included in claims for your application. https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-group-claims provides detailed information relevant to configuring group claims.
Your application (usually an API) may need to define permissions for the purpose of allowing other applications the ability to leverage OAuth consent to take actions on behalf of another user. This is an advanced topic and we'd recommend you talk with UW-IT about your goals and how to best achieve them. https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-configure-app-expose-web-apis#add-a-scope covers the process of creating a hypothetical OAuth scope for an example application. https://docs.microsoft.com/en-us/azure/api-management/api-management-howto-oauth2 covers the process of both setting up a scope and having a 2nd application leverage the scope of the 1st. https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent is a comprehensive introduction to OAuth scopes which are sometimes called API permissions or OAuth consent.
Your application may need to take advantage of well-known OAuth scopes (permissions) that other applications have published as available for use with consent. These can only be added to applications whose application object lives in the UW Entra ID, i.e. application objects which you own. You can add these to the application manifest or via the App Registrations interface's API permissions screen. Note that scopes which are of type 'Admin' will require UW-IT authorization, presuming a valid business need and adequate risk mitigations.
The Entra ID application identity is a bridge between the software providing the application's functionality and the Entra ID users who might use that software. Via User Assignment, you determine which user accounts are allowed to access the software via the identity integration, but via User Assignment you don't actually make any configuration change to the software itself. Lots of software, especially Software as a Service (SaaS), include the idea of an instantiation of each user within the software's configuration. This allows the software to customize the user experience by storing special information about the user, such as profile information, special access roles, and more. When the software has a local instantiation of each user, it tends to approach this one of three ways:
  1. An application administrator must create each local (to the software) instantiated user account (in addition to the Entra ID application user assignment). Likewise, removal of user accounts are the responsibility of the application administrator.
  2. The application creates each local instantiated user account "just in time" when an Entra ID user account shows up. The local user accounts tend not to be removed, unless the application administrator realizes this is a gap and fills it.
  3. SCIM provisioning is supported by the software. This requires that the software provides an API which can be called by the application integration platform, in this case, Entra ID.
Entra ID application provisioning refers to automatically creating user identities and roles in the applications that users need access to. In addition to creating user identities, automatic provisioning includes the maintenance and removal of user identities as status or roles change. If your application is pre-integrated, it may also support SCIM provisioning. In that case, there will be instructions on how to get it setup. If an application supports SCIM provisioning, you use the Enterprise Applications, Provisioning section to configure it & the Enterprise Applications, Provisioning logs section to review activity and troubleshoot. If your application is not pre-integrated, there are several possible paths depending on the scenario: There are a few gotchas:
  • Do not *EVER* choose to provision all users and groups. If you do this, UW-IT will disable your application as soon as we detect this configuration. Choose 'Sync only assigned users and groups'.
  • Provisioning leverages the assigned users and groups as its data source for what to provision. See 'User Assignment'.
  • Nested groups don't work well with provisioning; any nested group will not be provisioned nor will any users within that nested group. You'll need to use groups which do not have any groups as members.
  • If the users being provisioned already exist in the application prior to enabling provisioning, and exist in a different customer's instance of that SaaS application, then you likely will experience errors which you will have to work with the SaaS vendor to resolve.
  • Only application owners can review the provisioning logs for troubleshooting purposes.
For more information about how to add SCIM support to your application to achieve provisioning, see https://docs.microsoft.com/en-us/azure/active-directory/app-provisioning/.
Conditional Access (CA) is a powerful feature that allows security controls to be enforced at the time an access token is requested based on a variety of conditions. UW support for Conditional Access is limited at this time. If you feel you need a CA policy, send a request and we'll consider it. Conditional Access can lead to significant unexpected impacts, so we have to exercise judicious vetting and practices to prevent undesirable outcomes. Also note that many of the CA conditions possible may not be viable. A summary of the options is represented in this grid:
Assignments
Users and groups Include | Exclude
Cloud apps Include | Exclude
  User actions
  Register security information
Conditions
Sign-in risk (Entra ID Identity Protection, via Entra ID P2) High | Medium | Low | No risk
  Note: Typical risks are atypical travel, unusual login, malware linked ip, leaked creds, known attack pattern
Device platforms Include | Exclude
Locations Include | Exclude
Client apps Browser | Mobile apps and desktop clients | Modern authentication clients | Exchange ActiveSync clients | Other clients
Device State Include | Exclude, where {Device Hybrid Entra ID joined, Device marked as compliant}
Access controls
Block access  
Grant access Require Multi-Factor Authentication
  Require device to be marked as compliant
  Require Hybrid Entra ID Joined device
  Require approved client app
  Require app protection policy
  Terms of Use
  Require one of the selected controls
  Require all of the selected controls
Session Use app enforced restrictions
  Use Conditional access app control (Cloud App Security, via M365 A5) See https://docs.microsoft.com/en-us/cloud-app-security/proxy-intro-aad & https://docs.microsoft.com/en-us/cloud-app-security/session-policy-aad
  Sign-in frequency
  Persistent browser session
  Conditional Access is an extensive topic, with more information available at https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview. Developers may find https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-conditional-access-dev-guide useful.