Επεξεργασία

Κοινή χρήση μέσω

Integrating applications with Microsoft Entra ID and establishing a baseline of reviewed access

  • Άρθρο

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

Microsoft Entra ID Governance can be integrated with many applications, including well-known applications such as SAP R/3, SAP S/4HANA, and those using standards such as OpenID Connect, SAML, SCIM, SQL, LDAP, SOAP and REST. Through these standards, you can use Microsoft Entra ID 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 Microsoft Entra ID and enable identity governance features to be used for that application.

In order for Microsoft Entra ID Governance to be used for an application, the application must first be integrated with Microsoft Entra ID and represented in your directory. An application being integrated with Microsoft Entra ID means one of two requirements must be met:

  • The application relies upon Microsoft Entra ID for federated SSO, and Microsoft Entra ID controls authentication token issuance. If Microsoft Entra ID is the only identity provider for the application, then only users who are assigned to one of the application's roles in Microsoft Entra ID 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 Microsoft Entra ID. This fulfillment could be done through a provisioning protocol such as SCIM, by the application querying Microsoft Entra ID 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 Microsoft Entra ID, 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 Microsoft Entra ID, or aren't assigned to the application roles in Microsoft Entra ID, won't be included in access reviews of the application, until you assign them to the application roles. For more information, see Preparing for an access review of users' access to an application.

Integrate the application with Microsoft Entra ID 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 Microsoft Entra ID 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 Microsoft Entra ID.

Next, if the application implements a provisioning protocol, then you should configure Microsoft Entra ID to provision users to the application, so that Microsoft Entra ID 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 Microsoft Entra ID.

    1. Follow the tutorial to configure the application for federated SSO with Microsoft Entra ID.
    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, each user has only one role in the application, and the application relies upon Microsoft Entra ID to send a user's single application-specific role as a claim of a user signing into the application, then configure those app roles in Microsoft Entra ID on your application, and then assign each user to the application role. You can use the app roles UI to add those roles to the application manifest. If you're using the Microsoft Authentication Libraries, there is a code sample for how to use app roles inside your application for access control. If a user could have multiple roles simultaneously, then you may wish to implement the application to check security groups, either in the token claims or available via Microsoft Graph, instead of using app roles from the app manifest for access control.

  5. If the application supports provisioning, then configure provisioning of assigned users and groups from Microsoft Entra ID 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.

  6. If your application uses Microsoft Graph to query groups from Microsoft Entra ID, 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 prevents 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 sets 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 wasn't using Microsoft Entra ID 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 wasn't using Microsoft Entra ID or AD, and doesn't 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 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 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 Microsoft Entra ID and written back to Microsoft Entra ID, or move the membership from the AD group to the Microsoft Entra 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