add new connectors

MicrosoftDocs · Aug 29, 2023 · 7492be6 · 7492be6
1 parent 3bcd517
commit 7492be6
Show file tree

Hide file tree

Showing 6 changed files with 20 additions and 10 deletions.
diff --git a/docs/id-governance/access-reviews-application-preparation.md b/docs/id-governance/access-reviews-application-preparation.md
@@ -55,7 +55,7 @@ In order to permit a wide variety of applications and IT requirements to be addr
 |:---|---|--|
 |A| The application supports federated SSO, Azure AD is the only identity provider, and the application doesn't rely upon group or role claims. | In this pattern, you'll configure that the application requires individual application role assignments, and that users are assigned to the application.  Then to perform the review, you'll create a single access review for the application, of the users assigned to this application role. When the review completes, if a user was denied, then they will be removed from the application role. Azure AD will then no longer issue that user with federation tokens and the user will be unable to sign into that application.|
 |B|If the application uses group claims in addition to application role assignments.| An application may use AD or Azure AD group membership, distinct from application roles to express finer-grained access.  Here, you can choose based on your business requirements either to have the users who have application role assignments reviewed, or to review the users who have group memberships.  If the groups do not provide comprehensive access coverage, in particular if users may have access to the application even if they aren't a member of those groups, then we recommend reviewing the application role assignments, as in pattern A above.|
-|C| If the application doesn't rely solely on Azure AD for federated SSO, but does support provisioning via SCIM, or via updates to a SQL table of users or a non-AD LDAP directory. | In this pattern, you'll configure Azure AD to provision the users with application role assignments to the application's database or directory, update the application role assignments in Azure AD with a list of the users who currently have access, and then create a single access review of the application role assignments.  For more information, see [Governing an application's existing users](identity-governance-applications-existing-users.md)  to update the application role assignments in Azure AD.|
+|C| If the application doesn't rely solely on Azure AD for federated SSO, but does support provisioning via SCIM, via updates to a SQL table of users, has a non-AD LDAP directory, or supports a SOAP or REST provisioning protocol. | In this pattern, you'll configure Azure AD to provision the users with application role assignments to the application's database or directory, update the application role assignments in Azure AD with a list of the users who currently have access, and then create a single access review of the application role assignments.  For more information, see [Governing an application's existing users](identity-governance-applications-existing-users.md)  to update the application role assignments in Azure AD.|
 
 ### Other options
 
@@ -80,13 +80,16 @@ Now that you have identified the integration pattern for the application, check
 
 1. Change to the **Roles and administrators** tab. This tab displays the administrative roles, that give rights to control the representation of the application in Azure AD, not the access rights in the application.  For each administrative role that has permissions to allow changing the application integration or assignments, and has an assignment to that administrative role, ensure that only authorized users are in that role.
 
-1. Change to the **Provisioning** tab.  If automatic provisioning isn't configured, then Azure AD won't have a way to notify the application when a user's access is removed if denied during the review.  Provisioning might not be necessary for some integration patterns, if the application is federated and solely relies upon Azure AD as its identity provider, or the application uses AD DS groups. However, if your application integration is pattern C, and the application doesn't support federated SSO with Azure AD as its only identity provider, then you'll need to configure provisioning from Azure AD to the application. Provisioning will be necessary so that Azure AD can automatically remove the reviewed users from the application when a review completes, and this removal step can be done through a change sent from Azure AD to the application through SCIM, LDAP or SQL.
+1. Change to the **Provisioning** tab.  If automatic provisioning isn't configured, then Azure AD won't have a way to notify the application when a user's access is removed if denied during the review.  Provisioning might not be necessary for some integration patterns, if the application is federated and solely relies upon Azure AD as its identity provider, or the application uses AD DS groups. However, if your application integration is pattern C, and the application doesn't support federated SSO with Azure AD as its only identity provider, then you'll need to configure provisioning from Azure AD to the application. Provisioning will be necessary so that Azure AD can automatically remove the reviewed users from the application when a review completes, and this removal step can be done through a change sent from Azure AD to the application through SCIM, LDAP, SQL, SOAP or REST.
 
    * If this is a gallery application that supports provisioning, [configure the application for provisioning](../app-provisioning/configure-automatic-user-provisioning-portal.md).
    * If the application is a cloud application and supports SCIM, configure [user provisioning with SCIM](../app-provisioning/use-scim-to-provision-users-and-groups.md).
    * If the application is an on-premises application and supports SCIM, configure an application with the [provisioning agent for on-premises SCIM-based apps](../app-provisioning/on-premises-scim-provisioning.md).
    * If the application relies upon a SQL database, configure an application with the [provisioning agent for on-premises SQL-based applications](../app-provisioning/on-premises-sql-connector-configure.md).
    * If the application relies upon another LDAP directory, configure an application with the [provisioning agent for on-premises LDAP-based applications](../app-provisioning/on-premises-ldap-connector-configure.md).
+   * If the application has local user accounts, managed through a SOAP or REST API, configure an application with the [provisioning agent with the web services connector](../app-provisioning/on-premises-web-services-connector.md).
+   * If the application has local user accounts, managed through a MIM connector, configure an application with the [provisioning agent with a custom connector](../app-provisioning/on-premises-custom-connector.md).
+   * If the application is SAP ECC with NetWeaver AS ABAP 7.0 or later, configure an application with the [provisioning agent with a SAP ECC configured web services connector](../app-provisioning/on-premises-sap-connector-configure.md).
 
 1. If provisioning is configured, then click on **Edit Attribute Mappings**, expand the Mapping section and click on **Provision Azure Active Directory Users**. Check that in the list of attribute mappings, there is a mapping for `isSoftDeleted` to the attribute in the application's data store that you would like to set to false when a user loses access. If this mapping isn't present, then Azure AD will not notify the application when a user has gone out of scope, as described in [how provisioning works](../app-provisioning/how-provisioning-works.md).
 1. If the application supports federated SSO, then change to the **Conditional Access** tab. Inspect the enabled policies for this application. If there are policies that are enabled, block access, have users assigned to the policies, but no other conditions, then those users may be already blocked from being able to get federated SSO to the application.

diff --git a/docs/id-governance/identity-governance-applications-integrate.md b/docs/id-governance/identity-governance-applications-integrate.md
@@ -22,7 +22,7 @@ ms.collection: M365-identity-device-management
 
 Once you've [established the policies](identity-governance-applications-define.md) for who should have access to an application, then you can [connect your application to Azure AD](../manage-apps/what-is-application-management.md) and then [deploy the policies](identity-governance-applications-deploy.md) for governing access to them.
 
-Microsoft Entra identity governance can be integrated with many applications, using [standards](../architecture/auth-sync-overview.md) 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.
+Microsoft Entra identity governance can be integrated with many applications, including well-known applications such as SAP and those using [standards](../architecture/auth-sync-overview.md) such as OpenID Connect, SAML, SCIM, SQL, LDAP, SOAP and REST.  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:
 
@@ -84,6 +84,9 @@ Next, if the application implements a provisioning protocol, then you should con
      | SCIM | configure an application with the [provisioning agent for on-premises SCIM-based apps](../app-provisioning/on-premises-scim-provisioning.md)|
      | local user accounts, stored in a SQL database |  configure an application with the  [provisioning agent for on-premises SQL-based applications](../app-provisioning/on-premises-sql-connector-configure.md)|
      | local user accounts, stored in an LDAP directory | configure an application with the [provisioning agent for on-premises LDAP-based applications](../app-provisioning/on-premises-ldap-connector-configure.md) |
+     | local user accounts, managed through a SOAP or REST API | configure an application with the [provisioning agent with the web services connector](../app-provisioning/on-premises-web-services-connector.md)|
+     | local user accounts, managed through a MIM connector | configure an application with the [provisioning agent with a custom connector](../app-provisioning/on-premises-custom-connector.md)|
+     | SAP ECC with NetWeaver AS ABAP 7.0 or later | configure an application with the [provisioning agent with a SAP ECC configured web services connector](../app-provisioning/on-premises-sap-connector-configure.md)|
 
 1. If your application uses Microsoft Graph to query groups from Azure AD, then [consent](../develop/application-consent-experience.md) to the applications to have the appropriate permissions to read from your tenant.
 

diff --git a/docs/id-governance/identity-governance-applications-not-provisioned-users.md b/docs/id-governance/identity-governance-applications-not-provisioned-users.md
@@ -29,7 +29,7 @@ There are three common scenarios in which it's necessary to populate Azure Activ
  - Application that doesn't use Azure AD as its only identity provider
  - Application does not use Azure AD as its identity provider nor does it support provisioning
 
-For more information on those first two scenarios, where the application supports provisioning, or uses an LDAP directory, SQL database or relies upon Azure AD as its identity provider, see the article [govern an application's existing users](identity-governance-applications-existing-users.md). That article covers how to use identity governance features for existing users of those categories of applications.
+For more information on those first two scenarios, where the application supports provisioning, or uses an LDAP directory, SQL database, has a SOAP or REST API or relies upon Azure AD as its identity provider, see the article [govern an application's existing users](identity-governance-applications-existing-users.md). That article covers how to use identity governance features for existing users of those categories of applications.
 
 This article covers the third scenario. For some legacy applications it might not be feasible to remove other identity providers or local credential authentication from the application, or enable support for provisioning protocols for those applications. For those applications, if you want to use Azure AD to review who has access to that application, or remove someone's access from that application, you'll need to create assignments in Azure AD that represent application users.  This article covers that scenario of an application that does not use Azure AD as its identity provider and does not support provisioning.
 
@@ -242,7 +242,11 @@ Follow the instructions in the [guide for creating an access review of groups or
 
 1. The columns `PrincipalDisplayName` and `PrincipalId` contain the display names and Azure AD user IDs of each user who retains an application role assignment.
 
+## Configure entitlement management integration with ServiceNow for ticketing (optional)
+
+If you have ServiceNow then you can optionally configure automated ServiceNow ticket creation, using the [entitlement management integration](entitlement-management-ticketed-provisioning.md) via Logic Apps.  In that scenario, entitlement management can automatically create ServiceNow tickets for manual provisioning of users who have received access package assignments.
 
 ## Next steps
 
  - [Prepare for an access review of users' access to an application](access-reviews-application-preparation.md)
+ - [Automated ServiceNow ticket creation with entitlement management integration](entitlement-management-ticketed-provisioning.md)
diff --git a/docs/id-governance/identity-governance-applications-prepare.md b/docs/id-governance/identity-governance-applications-prepare.md
@@ -44,12 +44,12 @@ Microsoft Entra identity governance can be integrated with many applications, us
 
 Before you begin the process of governing application access from Azure AD, you should check your Azure AD environment is appropriately configured.
 
-* **Ensure your Azure AD and Microsoft Online Services environment is ready for the [compliance requirements](../standards/standards-overview.md) for the applications to be integrated and properly licensed**.  Compliance is a shared responsibility among Microsoft, cloud service providers (CSPs), and organizations.  To use Azure AD to govern access to applications, you must have one of the following licenses in your tenant:
+* **Ensure your Azure AD and Microsoft Online Services environment is ready for the [compliance requirements](../standards/standards-overview.md) for the applications to be integrated and properly licensed**.  Compliance is a shared responsibility among Microsoft, cloud service providers (CSPs), and organizations.  To use Azure AD to govern access to applications, you must have one of the following [license combinations](licensing-fundamentals.md) in your tenant:
 
-  * Microsoft Azure AD Premium P2 or Microsoft Entra ID Governance
-  * Enterprise Mobility + Security (EMS) E5 license
+  *  **Microsoft Entra ID Governance** and its prerequisite, Microsoft Azure AD Premium P1
+  * **Microsoft Entra ID Governance Step Up for Microsoft Entra ID P2** and its prerequisite, either Microsoft Azure AD Premium P2 or Enterprise Mobility + Security (EMS) E5
 
-   Your tenant needs to have at least as many licenses as the number of member (non-guest) users who have or can request access to the applications, approve, or review access to the applications.  With an appropriate license for those users, you can then govern access to up to 1500 applications per user.
+   Your tenant needs to have at least as many licenses as the number of member (non-guest) users who are governed, including those that have or can request access to the applications, approve, or review access to the applications.  With an appropriate license for those users, you can then govern access to up to 1500 applications per user.
 
 * **If you will be governing guest's access to the application, link your Azure AD tenant to a subscription for MAU billing**. This step is necessary prior to having a guest request or review their access. For more information, see [billing model for Azure AD External Identities](../external-identities/external-identities-pricing.md).
 

diff --git a/docs/id-governance/identity-governance-overview.md b/docs/id-governance/identity-governance-overview.md
@@ -54,7 +54,7 @@ Organizations need a process to manage access beyond what was initially provisio
 
 Typically, IT delegates access approval decisions to business decision makers.  Furthermore, IT can involve the users themselves.  For example, users that access confidential customer data in a company's marketing application in Europe need to know the company's policies. Guest users may be unaware of the handling requirements for data in an organization to which they've been invited.
 
-Organizations can automate the access lifecycle process through technologies such as [dynamic groups](../enterprise-users/groups-dynamic-membership.md), coupled with user provisioning to [SaaS apps](../saas-apps/tutorial-list.md) or [apps integrated with SCIM](../app-provisioning/use-scim-to-provision-users-and-groups.md). Microsoft Entra can also provision access to apps that use [AD groups](../enterprise-users/groups-write-back-portal.md), [other on-premises directories](../app-provisioning/on-premises-ldap-connector-configure.md) or [databases](../app-provisioning/on-premises-sql-connector-configure.md).  Organizations can also control which [guest users have access to on-premises applications](../external-identities/hybrid-cloud-to-on-premises.md).  These access rights can then be regularly reviewed using recurring [Microsoft Entra access reviews](access-reviews-overview.md).   [Microsoft Entra entitlement management](entitlement-management-overview.md) also enables you to define how users request access across packages of group and team memberships, application roles, and SharePoint Online roles.  For more information, see the [simplifying identity governance tasks with automation](#simplifying-identity-governance-tasks-with-automation) section below to select the appropriate Microsoft Entra features for your access lifecycle automation scenarios.
+Organizations can automate the access lifecycle process through technologies such as [dynamic groups](../enterprise-users/groups-dynamic-membership.md), coupled with user provisioning to [SaaS apps](../saas-apps/tutorial-list.md) or [apps integrated with SCIM](../app-provisioning/use-scim-to-provision-users-and-groups.md). Microsoft Entra can also provision access to apps that use [AD groups](../enterprise-users/groups-write-back-portal.md), [other on-premises directories](../app-provisioning/on-premises-ldap-connector-configure.md) or [databases](../app-provisioning/on-premises-sql-connector-configure.md), or that have a [SOAP or REST API](../app-provisioning/on-premises-web-services-connector.md) including [SAP](sap.md).  Organizations can also control which [guest users have access to on-premises applications](../external-identities/hybrid-cloud-to-on-premises.md).  These access rights can then be regularly reviewed using recurring [Microsoft Entra access reviews](access-reviews-overview.md).   [Microsoft Entra entitlement management](entitlement-management-overview.md) also enables you to define how users request access across packages of group and team memberships, application roles, and SharePoint Online roles.  For more information, see the [simplifying identity governance tasks with automation](#simplifying-identity-governance-tasks-with-automation) section below to select the appropriate Microsoft Entra features for your access lifecycle automation scenarios.
 
 Lifecycle access can be automated using workflows. [Workflows can be created](create-lifecycle-workflow.md) to automatically add user to groups, where access to applications and resources are granted. Users can also be moved when their condition within the organization changes to different groups, and can even be removed entirely from all groups.