Edit

Integrating applications with Azure AD and establishing a baseline of reviewed access

  • Article
  • 7 minutes to read

Once you've established the policies for who should have access to an application, then you can connect your application to Azure AD and then deploy the policies for governing access to them.

Microsoft Entra identity governance can be integrated with many applications, using standards such as OpenID Connect, SAML, SCIM, SQL and LDAP. Through these standards, you can use Azure AD with many popular SaaS applications and on-premises applications, including applications that your organization has developed. This deployment plan covers how to connect your application to Azure AD and enable identity governance features to be used for that application.

In order for Microsoft Entra identity governance to be used for an application, the application must first be integrated with Azure AD. An application being integrated with Azure AD means one of two requirements must be met:

  • The application relies upon Azure AD for federated SSO, and Azure AD controls authentication token issuance. If Azure AD is the only identity provider for the application, then only users who are assigned to one of the application's roles in Azure AD are able to sign into the application. Those users that lose their application role assignment can no longer get a new token to sign in to the application.
  • The application relies upon user or group lists that are provided to the application by Azure AD. This fulfillment could be done through a provisioning protocol such as SCIM, by the application querying Azure AD via Microsoft Graph, or the application using AD Kerberos to obtain a user's group memberships.

If neither of those criteria are met for an application, for example when the application doesn't rely upon Azure AD, then identity governance can still be used. However, there may be some limitations using identity governance without meeting the criteria. For instance, users that aren't in your Azure AD, or aren't assigned to the application roles in Azure AD, won't be included in access reviews of the application, until you add them to the application roles. For more information, see Preparing for an access review of users' access to an application.

Integrate the application with Azure AD to ensure only authorized users can access the application

Typically this process of integrating an application begins when you configure that application to rely upon Azure AD for user authentication, with a federated single sign-on (SSO) protocol connection, and then add provisioning. The most commonly used protocols for SSO are SAML and OpenID Connect. You can read more about the tools and process to discover and migrate application authentication to Azure AD.

Next, if the application implements a provisioning protocol, then you should configure Azure AD to provision users to the application, so that Azure AD can signal to the application when a user has been granted access or a user's access has been removed. These provisioning signals permit the application to make automatic corrections, such as to reassign content created by an employee who has left to their manager.

  1. Check if your application is on the list of enterprise applications or list of app registrations. If the application is already present in your tenant, then skip to step 5 in this section.

  2. If your application is a SaaS application that isn't already registered in your tenant, then check if the application is available the application gallery for applications that can be integrated for federated SSO. If it's in the gallery, then use the tutorials to integrate the application with Azure AD.

    1. Follow the tutorial to configure the application for federated SSO with Azure AD.
    2. if the application supports provisioning, configure the application for provisioning.
    3. When complete, skip to the next section in this article. If the SaaS application isn't in the gallery, then ask the SaaS vendor to onboard.

  3. If this is a private or custom application, you can also select a single sign-on integration that's most appropriate, based on the location and capabilities of the application.

  4. If your application has multiple roles, and relies upon Azure AD to send a user's application-specific role as a claim of a user signing into the application, then configure those application roles in Azure AD on your application. You can use the app roles UI to add those roles to the application manifest.

  5. If the application supports provisioning, then configure provisioning of assigned users and groups from Azure AD to that application. If this is a private or custom application, you can also select the integration that's most appropriate, based on the location and capabilities of the application.

    • If this application is in the public cloud and supports SCIM, then configure provisioning of users via SCIM.

      Application supports Next steps
      SCIM Configure an application with SCIM for user provisioning

    • If this application uses AD, then configure group writeback, and either update the application to use the Azure AD-created groups, or nest the Azure AD-created groups into the applications' existing AD security groups.

      Application supports Next steps
      Kerberos Configure Azure AD Connect group writeback to AD, create groups in Azure AD and write those groups to AD

    • Otherwise, if this is an on-premises or IaaS hosted application, and is not integrated with AD, then configure provisioning to that application, either via SCIM or to the underlying database or directory of the application.

      Application supports Next steps
      SCIM configure an application with the provisioning agent for on-premises SCIM-based apps
      local user accounts, stored in a SQL database configure an application with the provisioning agent for on-premises SQL-based applications
      local user accounts, stored in an LDAP directory configure an application with the provisioning agent for on-premises LDAP-based applications

  6. If your application uses Microsoft Graph to query groups from Azure AD, then consent to the applications to have the appropriate permissions to read from your tenant.

  7. Set that access to the application is only permitted for users assigned to the application. This setting will prevent users from inadvertently seeing the application in MyApps, and attempting to sign into the application, prior to Conditional Access policies being enabled.

Perform an initial access review

If this is a new application your organization hasn't used before, and therefore no one has pre-existing access, or if you've already been performing access reviews for this application, then skip to the next section.

However, if the application already existed in your environment, then it's possible that users may have gotten access in the past through manual or out-of-band processes, and those users should now be reviewed to have confirmation that their access is still needed and appropriate going forward. We recommend performing an access review of the users who already have access to the application, before enabling policies for more users to be able to request access. This review will set a baseline of all users having been reviewed at least once, to ensure that those users are authorized for continued access.

  1. Follow the steps in Preparing for an access review of users' access to an application.
  2. If the application was not using Azure AD or AD, but does support a provisioning protocol or had an underlying SQL or LDAP database, bring in any existing users and create application role assignments for them.
  3. If the application was not using Azure AD or AD, and does not support a provisioning protocol, then obtain a list of users from the application and create application role assignments for each of them.
  4. If the application was using AD security groups, then you'll need to review the membership of those security groups.
  5. If the application had its own directory or database and wasn't integrated for provisioning, then once the review is complete, you may need to manually update the application's internal database or directory to remove those users who were denied.
  6. If the application was using AD security groups, and those groups were created in AD, then once the review is complete, you'll need to manually update the AD groups to remove memberships of those users who were denied. Subsequently, to have denied access rights removed automatically, you can either update the application to use an AD group that was created in Azure AD and written back to Azure AD, or move the membership from the AD group to the Azure AD group, and nest the written back group as the only member of the AD group.
  7. Once the review has been completed and the application access updated, or if no users have access, then continue on to the next steps to deploy conditional access and entitlement management policies for the application.

Now that you have a baseline that ensures existing access has been reviewed, then you can deploy the organization's policies for ongoing access and any new access requests.

Next steps