Merge pull request #230654 from MicrosoftDocs/main

3/14 AM Publish

Author: huypub

articles/active-directory-b2c/partner-biocatch.md

@@ -4,82 +4,78 @@ titleSuffix: Azure AD B2C
 description: Tutorial to configure Azure Active Directory B2C with BioCatch to identify risky and fraudulent users
 services: active-directory-b2c
 author: gargi-sinha
-manager: CelesteDG
+manager: martinco
 ms.reviewer: kengaderdus
-
 ms.service: active-directory
 ms.workload: identity
 ms.topic: how-to
-ms.date: 09/20/2021
+ms.date: 03/13/2023
 ms.author: gasinh
 ms.subservice: B2C
 ---
 
 # Tutorial: Configure BioCatch with Azure Active Directory B2C
 
-In this sample tutorial, learn how to integrate Azure Active Directory (AD) B2C authentication with [BioCatch](https://www.biocatch.com/) to further augment your Customer Identity and Access Management (CIAM) security posture. BioCatch analyzes a user's physical and cognitive digital behaviors to generate insights that distinguish between legitimate customers and cyber-criminals.
-
-## Prerequisites
+Learn how to integrate Azure Active Directory B2C (Azure AD B2C) authentication with BioCatch technology to augment your Customer Identity and Access Management (CIAM) security posture. BioCatch products analyze user physical and cognitive digital behaviors for insights that help distinguish legitimate customers.
 
-To get started, you'll need:
+Go to biocatch.com to learn more [BioCatch](https://www.biocatch.com/)
 
-- An Azure subscription. If you don't have a subscription, you can get a [free account](https://azure.microsoft.com/free/).
+## Prerequisites
 
-- [An Azure AD B2C tenant](tutorial-create-tenant.md) that is linked to your Azure subscription.
+To get started, you need:
 
-- A [BioCatch](https://www.biocatch.com/contact-us) account.
+* An Azure subscription
+  * If you don't have one, get an [Azure free account](https://azure.microsoft.com/free/)
+* An Azure AD B2C tenant linked to the Azure subscription
+  * See, [Tutorial: Create an Azure Active Directory B2C tenant](tutorial-create-tenant.md)
+* Go to the biocatch.com [Contact Us](https://www.biocatch.com/contact-us) page to request an account
+  * Mention Azure AD B2C integration
 
 ## Scenario description
 
 BioCatch integration includes the following components:
 
-- **A web app or web service** - The user first browses to this web service. This web service instantiates a unique client session ID that is sent to BioCatch. The client session ID then immediately begins transmitting user behavior characteristics to BioCatch.
-
-- **A method** - Sends the unique client session ID to Azure AD B2C. In the provided example, JavaScript is used to input the value into a hidden HTML field.
-
-- **An Azure AD B2C customized UI** - Hides an HTML field for the client session ID input from JavaScript, if using the above method
-
-- **Azure AD B2C custom policy**
+* **A web app or web service** - users browse to this web service that instantiates a unique client session ID that goes to BioCatch 
+  * The session ID transmits user behavior characteristics to BioCatch
+* **A method** - sends the session ID to Azure AD B2C. In the example, JavaScript inputs the value into a hidden HTML field.
+* **An Azure AD B2C customized UI** - hides an HTML field for the session ID input from JavaScript
+* **Azure AD B2C custom policy**:
+  * Takes the session ID as a claim via a self-asserted technical profile
+  * Integrates with BioCatch via a REST API claims provider and passes the session ID to BioCatch
+  * Multiple custom claims return from BioCatch for the custom policy logic 
+  * A user journey evaluates a returned claim, and executes a conditional action, such as multi-factor authentication
 
-  - Takes the custom client session ID from the UI in the form of a claim. This is achieved via a self-asserted technical profile
+Learn more: 
 
-  - Integrates with BioCatch via a REST API claims provider and passes the client session ID to the BioCatch platform
+* [Azure AD B2C custom policy overview](custom-policy-overview.md)
+* [Tutorial: Create user flows and custom policies in Azure AD B2C](./tutorial-create-user-flows.md?pivots=b2c-custom-policy&tabs=applications)
 
-  - Multiple custom claims are returned from BioCatch for the custom policy logic to then act upon
+The following diagram illustrates user flows with session information. 
 
-  - A userjourney, which evaluates a returned claim, for example, session risk, and conditionally executes an action, such as invoke Multi-factor authentication (MFA).
+   ![Diagram of user flows with session information.](media/partner-biocatch/biocatch-architecture-diagram.png)
 
-![Diagram of the bio catch architecture.](media/partner-biocatch/biocatch-architecture-diagram.png)
+1. The user browses to the web service, which returns HTML, CSS, or JavaScript values, then loads the BioCatch JavaScript SDK. Client-side JavaScript configures a client session ID for the BioCatch SDK. Alternately, the web service pre-configures client session ID and sends it to the client. You can configure the instantiated BioCatch JavaScript SDK for BioCatch, which sends user behavior to BioCatch from the client device, using the client session ID.
+2. User signs-up or signs-in and is redirected to Azure AD B2C. 
+3. The user journey includes a self-asserted claims provider, which inputs the client session ID. This field is hidden. Use JavaScript to input the session ID into the field. Select **Next**, to continue sign-up or sign-in. The session ID goes to BioCatch for a risk score. BioCatch returns session information, and recommends allow or block. The user journey has a conditional check, which acts upon the returned claims.
+4. Based on the conditional check result, an action is invoked.
+5. The web service can use the session ID to query BioCatch API to determine risk and session information.
 
-| Step  | Description |
-|:---|:-----------------------|
-|1a     | The user browses the web service. The web service then returns HTML, CSS, or JavaScript values and configures to load the BioCatch JavaScript SDK. Client-side JavaScript configures/sets client session ID for the BioCatch SDK. Alternately, the web service can pre-configure client session ID and send to the client.        |
-|1b    |  Configure the instantiated BioCatch JavaScript SDK against the BioCatch platform. Immediately begin to send user behavior characteristics to BioCatch from the client device, using the client session ID from step 1a.    |
-|2     |  User tries to sign-up/sign-in and is redirected to Azure AD B2C.      |
-|3a    | Part of the userjourney is a self-asserted claimsprovider, which takes the client session ID as input. This field is hidden on the screen. You can use JavaScript to input the session ID into the field. Select the *next* button, to continue the sign-up/sign-in process.|
-|3b     | The client session ID is submitted to the BioCatch platform to determine a risk score. |
-|3c     | BioCatch returns information about the session, such as risk score, and a recommendation on what to do – allow or block |
-|3d    |The userjourney has a conditional check step, which acts upon the returned claims|
-| 4   | Based on the conditional check result, an action such as *step-up MFA* is invoked|
-|5    | At any time from when the user first hits the web service page, the web service can use the client session ID to query the BioCatch API to determine risk score and session information in real-time. |
+## Get started with BioCatch
 
-## Onboard with BioCatch
-
-Contact [BioCatch](https://www.biocatch.com/contact-us) and create an account.
+Go to the biocatch.com [Contact Us](https://www.biocatch.com/contact-us) page to initiate an account.
 
 ## Configure the custom UI
 
-It's recommended to hide the client session ID field. Use CSS, JavaScript, or any other method to hide the field. For testing purposes, you may unhide the field. For example, JavaScript is used to hide the input field as:
+We recommended you hide the Client Session ID field with CSS, JavaScript, or another method. For testing, unhide the field. For example, JavaScript hides the input field as:
 
 ```JavaScript
 document.getElementById("clientSessionId").style.display = 'none';
 ```
 
-## Configure  Azure AD B2C Identity Experience Framework policies
-
-1. Configure the initial [custom policy configuration](./tutorial-create-user-flows.md?pivots=b2c-custom-policy).
+## Configure Azure AD B2C Identity Experience Framework policies
 
-2. Create a new file, which inherits from the extensions file.
+1. To get started, See [Tutorial: Create user flows and custom policies in Azure AD B2C](./tutorial-create-user-flows.md?pivots=b2c-custom-policy).
+2. Create a new file that inherits from the extensions file.
 
     ```xml
     <BasePolicy> 
@@ -107,7 +103,7 @@ document.getElementById("clientSessionId").style.display = 'none';
         </ContentDefinitions>
     ```
 
-4. Add the following claims under the BuildingBlocks resource.
+4. Under the BuildingBlocks resource, add the following claims.
 
     ```xml
     <ClaimsSchema> 
@@ -141,7 +137,7 @@ document.getElementById("clientSessionId").style.display = 'none';
     </ClaimsSchema> 
     ```
 
-5. Configure self-asserted claims provider for the client session ID field.
+5. Configure a self-asserted claims provider for the client session ID field.
 
     ```xml
     <ClaimsProvider> 
@@ -185,7 +181,7 @@ document.getElementById("clientSessionId").style.display = 'none';
         </ClaimsProvider> 
     ```
 
-6. Configure REST API claims provider for BioCatch. 
+6. Configure a REST API claims provider for BioCatch. 
 
     ```xml
     <TechnicalProfile Id="BioCatch-API-GETSCORE"> 
@@ -234,15 +230,13 @@ document.getElementById("clientSessionId").style.display = 'none';
     ```
 
     > [!NOTE]
-    > BioCatch will provide you the URL, customer ID and unique user ID (UUID) to configure. The customer SessionID claim is passed through as a query string parameter to BioCatch. You can choose the activity type, for example *MAKE_PAYMENT*.
-
-7. Configure the userjourney; follow the example
-
-   1. Get the clientSessionID as a claim
+    > BioCatch provides the URL, customer ID, and unique user ID (UUID). The customer SessionID claim passes through as a query string parameter to BioCatch. You can select the activity type, for example **MAKE_PAYMENT**.
 
-   1. Call the BioCatch API to get the session information
+7. Configure the user journey using the following example:
 
-   1. If the returned claim *risk* equals *low*, skip the step for MFA, else force user MFA
+   * Get the clientSessionID as a claim.
+   * Call BioCatch API to get the session information.
+   * If the returned claim risk is **low**, skip the step for MFA, otherwise enforce user MFA.
 
     ```xml
     <OrchestrationStep Order="8" Type="ClaimsExchange"> 
@@ -288,9 +282,7 @@ document.getElementById("clientSessionId").style.display = 'none';
           </ClaimsExchanges>
     ```
 
-8. Configure on relying party configuration (optional)
-
-    It is useful to pass the BioCatch returned information to your application as claims in the token, specifically *risklevel* and *score*.
+8. Configure relying party (optional). You can pass the BioCatch returned information to your application as claims in the token: risklevel and score.
 
     ```xml
     <RelyingParty> 
@@ -346,21 +338,28 @@ document.getElementById("clientSessionId").style.display = 'none';
 
 ## Integrate with Azure AD B2C
 
-Follow these steps to add the policy files to Azure AD B2C
+Add the policy files to Azure AD B2C. For the following instructions, use the directory with the Azure AD B2C tenant. 
 
-1. Sign in to the [**Azure portal**](https://portal.azure.com/) as the global administrator of your Azure AD B2C tenant.
-1. Make sure you're using the directory that contains your Azure AD B2C tenant. Select the **Directories + subscriptions** icon in the portal toolbar.
-1. On the **Portal settings | Directories + subscriptions** page, find your Azure AD B2C directory in the **Directory name** list, and then select **Switch**.
-1. Choose **All services** in the top-left corner of the Azure portal, search for and select Azure AD B2C.
-1. Navigate to **Azure AD B2C** > **Identity Experience Framework**
-1. Upload all the policy files to your tenant.
+1. Sign in to the [**Azure portal**](https://portal.azure.com/) as the Global Administrator of the Azure AD B2C tenant.
+1. In the portal toolbar, select **Directories + subscriptions**.
+1. On the **Portal settings, Directories + subscriptions** page, in the **Directory name** list, locate the Azure AD B2C directory.
+2. Select **Switch**.
+3. In the top-left corner of the Azure portal, select **All services**.
+4. Search for and select **Azure AD B2C**.
+5. Navigate to **Azure AD B2C** > **Identity Experience Framework**.
+6. Upload the policy files to the tenant.
 
 ## Test the solution
 
-1. [Register a dummy application, which redirects to JWT.MS](./tutorial-register-applications.md?tabs=app-reg-ga)  
-1. Under the **Identity Experience Framework**, select the policy you created
-1. In the policy window, select the dummy JWT.MS application, and select **run now**
-1. Go through sign-up flow and create an account. Token returned to JWT.MS should have 2x claims for riskLevel and score. Follow the example.  
+For the following instructions, see [Tutorial: Register a web application in Azure Active Directory B2C](./tutorial-register-applications.md?tabs=app-reg-ga)
+
+1. Register a dummy application that redirects to JWT.MS. 
+2. Under **Identity Experience Framework**, select the policy you created.
+3. In the policy window, select the dummy JWT.MS application
+4. Select **run now**.
+5. Perform a sign-up flow and create an account. 
+6. The token returned to JWT.MS has 2x claims for riskLevel and score. 
+7. Use the following example.  
 
     ```JavaScript
     { 
@@ -413,6 +412,5 @@ Follow these steps to add the policy files to Azure AD B2C
 
 ## Additional resources
 
-- [Custom policies in Azure AD B2C](./custom-policy-overview.md)
-
-- [Get started with custom policies in Azure AD B2C](./tutorial-create-user-flows.md?pivots=b2c-custom-policy&tabs=applications)
+* [Azure AD B2C custom policy overview](./custom-policy-overview.md)
+* [Tutorial: Create user flows and custom policies in Azure AD B2C](./tutorial-create-user-flows.md?pivots=b2c-custom-policy&tabs=applications)

articles/active-directory/app-provisioning/use-scim-to-provision-users-and-groups.md

@@ -8,7 +8,7 @@ ms.service: active-directory
 ms.subservice: app-provisioning
 ms.workload: identity
 ms.topic: tutorial
-ms.date: 03/10/2023
+ms.date: 03/14/2023
 ms.author: kenwith
 ms.reviewer: arvinh
 ---
@@ -18,7 +18,7 @@ As an application developer, you can use the System for Cross-Domain Identity Ma
 
 ![Provisioning from Azure AD to an app with SCIM](media/use-scim-to-provision-users-and-groups/scim-provisioning-overview.png)
 
-SCIM 2.0 is a standardized definition of two endpoints: a `/Users` endpoint and a `/Groups` endpoint. It uses common REST API endpoints to create, update, and delete objects. The SCIM consists of a pre-defined schema for common attributes like group name, username, first name, last name and email. 
+SCIM 2.0 is a standardized definition of two endpoints: a `/Users` endpoint and a `/Groups` endpoint. It uses common REST API endpoints to create, update, and delete objects. The SCIM consists of a predefined schema for common attributes like group name, username, first name, last name and email. 
 
 Apps that offer a SCIM 2.0 REST API can reduce or eliminate the pain of working with a proprietary user management API. For example, any compliant SCIM client knows how to make an HTTP POST of a JSON object to the `/Users` endpoint to create a new user entry. Instead of needing a slightly different API for the same basic actions, apps that conform to the SCIM standard can instantly take advantage of pre-existing clients, tools, and code. 
 
@@ -195,7 +195,7 @@ Use the general guidelines when implementing a SCIM endpoint to ensure compatibi
 * Don't require a case-sensitive match on structural elements in SCIM, in particular **PATCH** `op` operation values, as defined in [section 3.5.2](https://tools.ietf.org/html/rfc7644#section-3.5.2). Azure AD emits the values of `op` as **Add**, **Replace**, and **Remove**.
 * Microsoft Azure AD makes requests to fetch a random user and group to ensure that the endpoint and the credentials are valid. It's also done as a part of the **Test Connection** flow in the [Azure portal](https://portal.azure.com). 
 * Support HTTPS on your SCIM endpoint.
-* Custom complex and multivalued attributes are supported but Azure AD doesn't have many complex data structures to pull data from in these cases. Name/value attributes can be mapped to easily, but flowing data to complex attributes with three or more sub-attributes isn't supported.
+* Custom complex and multivalued attributes are supported but Azure AD doesn't have many complex data structures to pull data from in these cases. Name/value attributes can be mapped to easily, but flowing data to complex attributes with three or more subattributes isn't supported.
 * The "type" subattribute values of multivalued complex attributes must be unique. For example, there can't be two different email addresses with the "work" subtype.
 * The header for all the responses should be of content-Type: application/scim+json 
 
@@ -1374,7 +1374,7 @@ The SCIM spec doesn't define a SCIM-specific scheme for authentication and autho
 |--|--|--|--|
 |Username and password (not recommended or supported by Azure AD)|Easy to implement|Insecure - [Your Pa$$word doesn't matter](https://techcommunity.microsoft.com/t5/azure-active-directory-identity/your-pa-word-doesn-t-matter/ba-p/731984)|Not supported for new gallery or non-gallery apps.|
 |Long-lived bearer token|Long-lived tokens don't require a user to be present. They're easy for admins to use when setting up provisioning.|Long-lived tokens can be hard to share with an admin without using insecure methods such as email. |Supported for gallery and non-gallery apps. |
-|OAuth authorization code grant|Access tokens have a shorter life than passwords, and have an automated refresh mechanism that long-lived bearer tokens don't have.  A real user must be present during initial authorization, adding a level of accountability. |Requires a user to be present. If the user leaves the organization, the token is invalid, and authorization will need to be completed again.|Supported for gallery apps, but not non-gallery apps. However, you can provide an access token in the UI as the secret token for short term testing purposes. Support for OAuth code grant on non-gallery is in our backlog, in addition to support for configurable auth / token URLs on the gallery app.|
+|OAuth authorization code grant|Access tokens have a shorter life than passwords, and have an automated refresh mechanism that long-lived bearer tokens don't have.  A real user must be present during initial authorization, adding a level of accountability. |Requires a user to be present. If the user leaves the organization, the token is invalid, and authorization needs to be completed again.|Supported for gallery apps, but not non-gallery apps. However, you can provide an access token in the UI as the secret token for short term testing purposes. Support for OAuth code grant on non-gallery is in our backlog, in addition to support for configurable auth / token URLs on the gallery app.|
 |OAuth client credentials grant|Access tokens have a shorter life than passwords, and have an automated refresh mechanism that long-lived bearer tokens don't have. Both the authorization code grant and the client credentials grant create the same type of access token, so moving between these methods is transparent to the API.  Provisioning can be automated, and new tokens can be silently requested without user interaction. ||Supported for gallery apps, but not non-gallery apps. However, you can provide an access token in the UI as the secret token for short term testing purposes. Support for OAuth client credentials grant on non-gallery is in our backlog.|
 
 > [!NOTE]