Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into sharedUltra

Author: roygara

.openpublishing.publish.config.json

@@ -164,6 +164,12 @@
       "branch": "dev",
       "branch_mapping": {}
     },
+    {
+      "path_to_root": "functions-quickstart-templates-v1",
+      "url": "https://github.com/Azure/azure-functions-templates",
+      "branch": "v1.x",
+      "branch_mapping": {}
+    },
     {
       "path_to_root": "azure-functions-samples-java",
       "url": "https://github.com/Azure-Samples/azure-functions-samples-java",

articles/active-directory-b2c/self-asserted-technical-profile.md

@@ -9,7 +9,7 @@ manager: CelesteDG
 ms.service: active-directory
 ms.workload: identity
 ms.topic: reference
-ms.date: 02/17/2022
+ms.date: 11/07/2022
 ms.author: kengaderdus
 ms.subservice: B2C
 ---
@@ -50,8 +50,6 @@ In a self-asserted technical profile, you can use the **InputClaims** and **Inpu
 
 ## Display claims
 
-The display claims feature is currently in **preview**.
-
 The **DisplayClaims** element contains a list of claims to be presented on the screen for collecting data from the user. To prepopulate the values of display claims, use the input claims that were previously described. The element may also contain a default value.
 
 The order of the claims in **DisplayClaims** specifies the order in which Azure AD B2C renders the claims on the screen. To force the user to provide a value for a specific claim, set the **Required** attribute of the **DisplayClaim** element to `true`.
@@ -133,7 +131,7 @@ Use output claims when:
 - **Claims are output by output claims transformation**.
 - **Setting a default value in an output claim** without collecting data from the user or returning the data from the validation technical profile. The `LocalAccountSignUpWithLogonEmail` self-asserted technical profile sets the **executed-SelfAsserted-Input** claim to `true`.
 - **A validation technical profile returns the output claims** - Your technical profile may call a validation technical profile that returns some claims. You may want to bubble up the claims and return them to the next orchestration steps in the user journey. For example, when signing in with a local account, the self-asserted technical profile named `SelfAsserted-LocalAccountSignin-Email` calls the validation technical profile named `login-NonInteractive`. This technical profile validates the user credentials and also returns the user profile. Such as 'userPrincipalName', 'displayName', 'givenName' and 'surName'.
-- **A display control returns the output claims** - Your technical profile may have a reference to a [display control](display-controls.md). The display control returns some claims, such as the verified email address. You may want to bubble up the claims and return them to the next orchestration steps in the user journey. The display control feature is currently in **preview**.
+- **A display control returns the output claims** - Your technical profile may have a reference to a [display control](display-controls.md). The display control returns some claims, such as the verified email address. You may want to bubble up the claims and return them to the next orchestration steps in the user journey. 
 
 The following example demonstrates the use of a self-asserted technical profile that uses both display claims and output claims.
 

articles/active-directory/develop/TOC.yml

@@ -183,6 +183,8 @@
           href: app-resilience-continuous-access-evaluation.md
         - name: Claims challenges and requests
           href: claims-challenge.md
+        - name: Configure app instance property lock
+          href: howto-configure-app-instance-property-locks.md
     - name: Test
       items:
         - name: Build a test environment

articles/active-directory/develop/active-directory-saml-protocol-reference.md

@@ -9,9 +9,9 @@ ms.service: active-directory
 ms.subservice: develop
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 10/27/2021
+ms.date: 11/4/2022
 ms.author: kenwith
-ms.custom: aaddev
+ms.custom: aaddev, engagement-fy23
 ms.reviewer: paulgarn
 ---
 
@@ -23,14 +23,17 @@ The SAML protocol requires the identity provider (Microsoft identity platform) a
 
 When an application is registered with Azure AD, the app developer registers federation-related information with Azure AD. This information includes the **Redirect URI** and **Metadata URI** of the application.
 
-The Microsoft identity platform uses the cloud service's **Metadata URI** to retrieve the signing key and the logout URI. In the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>, you can open the app in **Azure Active Directory -> App registrations**, and then in **Manage -> Authentication**, you can update the Logout URL. This way the Microsoft identity platform can send the response to the correct URL.
+The Microsoft identity platform uses the cloud service's **Metadata URI** to retrieve the signing key and the logout URI. This way the Microsoft identity platform can send the response to the correct URL. In the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>; 
 
-Azure AD exposes tenant-specific and common (tenant-independent) SSO and single sign-out endpoints. These URLs represent addressable locations--they're not just identifiers--so you can go to the endpoint to read the metadata.
+- Open the app in **Azure Active Directory** and select **App registrations**
+- Under **Manage**, select **Authentication**. From there you can update the Logout URL. 
 
-- The tenant-specific endpoint is located at `https://login.microsoftonline.com/<TenantDomainName>/FederationMetadata/2007-06/FederationMetadata.xml`. The _\<TenantDomainName>_ placeholder represents a registered domain name or TenantID GUID of an Azure AD tenant. For example, the federation metadata of the contoso.com tenant is at: https://login.microsoftonline.com/contoso.com/FederationMetadata/2007-06/FederationMetadata.xml
+Azure AD exposes tenant-specific and common (tenant-independent) SSO and single sign-out endpoints. These URLs represent addressable locations, and aren't only identifiers. You can then go to the endpoint to read the metadata.
+
+- The tenant-specific endpoint is located at `https://login.microsoftonline.com/<TenantDomainName>/FederationMetadata/2007-06/FederationMetadata.xml`. The *\<TenantDomainName>* placeholder represents a registered domain name or TenantID GUID of an Azure AD tenant. For example, the federation metadata of the `contoso.com` tenant is at: https://login.microsoftonline.com/contoso.com/FederationMetadata/2007-06/FederationMetadata.xml
 
 - The tenant-independent endpoint is located at
-  `https://login.microsoftonline.com/common/FederationMetadata/2007-06/FederationMetadata.xml`. In this endpoint address, **common** appears instead of a tenant domain name or ID.
+  `https://login.microsoftonline.com/common/FederationMetadata/2007-06/FederationMetadata.xml`. In this endpoint address, *common* appears instead of a tenant domain name or ID.
 
 ## Next steps
 

articles/active-directory/develop/howto-configure-app-instance-property-locks.md

@@ -0,0 +1,54 @@
+---
+title: "How to configure app instance property lock in your applications"
+description: How to increase app security by configuring property modification locks for sensitive properties of the application.
+services: active-directory
+manager: saumadan
+ms.service: active-directory
+ms.subservice: develop
+ms.topic: conceptual
+ms.workload: identity
+ms.date: 11/03/2022
+author: madansr7
+ms.author: saumadan
+ms.reviewer:
+# Customer intent: As an application developer, I want to learn how to protect properties of my application instance of being modified.
+---
+# How to configure app instance property lock for your applications (Preview)
+
+Application instance lock is a feature in Azure Active Directory (Azure AD) that allows sensitive properties of a multi-tenant application object to be locked for modification after the application is provisioned in another tenant. 
+This feature provides application developers with the ability to lock certain properties if the application doesn't support scenarios that require configuring those properties.  
+
+
+## What are sensitive properties?
+
+The following property usage scenarios are considered as sensitive:
+
+- Credentials (`keyCredentials`, `passwordCredentials`) where usage type is `Sign`. This is a scenario where your application supports a SAML flow.
+- Credentials (`keyCredentials`, `passwordCredentials`) where usage type is `Verify`. In this scenario, your application supports an OIDC client credentials flow.
+- `TokenEncryptionKeyId` which specifies the keyId of a public key from the keyCredentials collection. When configured, Azure AD encrypts all the tokens it emits by using the key to which this property points. The application code that receives the encrypted token must use the matching private key to decrypt the token before it can be used for the signed-in user.
+
+## Configure an app instance lock
+
+To configure an app instance lock using the Azure portal:
+
+1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>.
+1. If you have access to multiple tenants, use the **Directories + subscriptions** filter :::image type="icon" source="./media/common/portal-directory-subscription-filter.png" border="false"::: in the top menu to switch to the tenant that contains the app registration you want to configure. 
+1. Search for and select **Azure Active Directory**.
+1. Under **Manage**, select **App registrations**, and then select the application you want to configure.
+1. Select **Authentication**, and then select **Configure** under the *App instance property lock* section.
+
+   :::image type="content" source="media/howto-configure-app-instance-property-locks/app-instance-lock-configure-overview.png" alt-text="Screenshot of an app registration's app instance lock in the Azure portal.":::
+
+2. In the **App instance property lock** pane, enter the settings for the lock. The table following the image describes each setting and their parameters.
+
+   :::image type="content" source="media/howto-configure-app-instance-property-locks/app-instance-lock-configure-properties.png" alt-text="Screenshot of an app registration's app instance property lock context pane in the Azure portal.":::
+
+   | Field                                    | Description                                                                                                                                                                                                                                                                                                       |
+   | ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+   | **Enable property lock**                 | Specifies if the property locks are enabled.    | 
+   | **All properties**                 | Locks all sensitive properties without needing to select each property scenario. |
+   | **Credentials used for verification**                                | Locks the ability to add or update credential properties (`keyCredentials`, `passwordCredentials`) where usage type is `verify`. | 
+   | **Credentials used for signing tokens**                                | Locks the ability to add or update credential properties (`keyCredentials`, `passwordCredentials`) where usage type is `sign`. | 
+   | **Token Encryption KeyId**                                | Locks the ability to change the `tokenEncryptionKeyId` property.  | 
+
+3. Select **Save** to save your changes.

articles/active-directory/develop/media/howto-configure-app-instance-property-locks/app-instance-lock-configure-overview.png

@@ -17,7 +17,7 @@ ms.custom: aaddev
 
 # Single-page application: Acquire a token to call an API
 
-The pattern for acquiring tokens for APIs with [MSAL.js](https://github.com/AzureAD/microsoft-authentication-library-for-js) is to first attempt a silent token request by using the `acquireTokenSilent` method. When this method is called, the library first checks the cache in browser storage to see if a non-expired access token exists and returns it. If no access token is found for the given parameters, it will throw an `InteractionRequiredAuthError`, which should be handled with an interactive token request method (`acquireTokenPopup` or `acquireTokenRedirect`). If an access token is found but it's expired, it attempts to use its refresh token to get a fresh access token. If the refresh token's 24-hour lifetime has also expired, MSAL.js will open a hidden iframe to silently request a new authorization code by leveraging the existing active session with Azure AD (if any), which will then be exchanged for a fresh set of tokens (access _and_ refresh tokens). For more information about single sign-on (SSO) session and token lifetime values in Azure AD, see [Token lifetimes](active-directory-configurable-token-lifetimes.md). For more information on MSAL.js cache lookup policy, see: [Acquiring an Access Token](https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/acquire-token.md#acquiring-an-access-token).
+The pattern for acquiring tokens for APIs with [MSAL.js](https://github.com/AzureAD/microsoft-authentication-library-for-js) is to first attempt a silent token request by using the `acquireTokenSilent` method. When this method is called, the library first checks the cache in browser storage to see if a non-expired access token exists and returns it. If no access token is found or the access token found has expired, it attempts to use its refresh token to get a fresh access token. If the refresh token's 24-hour lifetime has also expired, MSAL.js will open a hidden iframe to silently request a new authorization code by leveraging the existing active session with Azure AD (if any), which will then be exchanged for a fresh set of tokens (access _and_ refresh tokens). For more information about single sign-on (SSO) session and token lifetime values in Azure AD, see [Token lifetimes](active-directory-configurable-token-lifetimes.md). For more information on MSAL.js cache lookup policy, see: [Acquiring an Access Token](https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/acquire-token.md#acquiring-an-access-token).
 
 The silent token requests to Azure AD might fail for reasons like a password change or updated conditional access policies. More often, failures are due to the refresh token's 24-hour lifetime expiring and [the browser blocking third party cookies](reference-third-party-cookies-spas.md), which prevents the use of hidden iframes to continue authenticating the user. In these cases, you should invoke one of the interactive methods (which may prompt the user) to acquire tokens:
 

articles/active-directory/develop/media/howto-configure-app-instance-property-locks/app-instance-lock-configure-properties.png

@@ -52,7 +52,7 @@ Create a folder to host your application, for example *ElectronDesktopApp*.
 
     ```console
     npm init -y
-    npm install --save @azure/msal-node @microsoft/microsoft-graph-sdk isomorphic-fetch bootstrap jquery popper.js
+    npm install --save @azure/msal-node @microsoft/microsoft-graph-client isomorphic-fetch bootstrap jquery popper.js
     npm install --save-dev [email protected]
     ```
 

articles/active-directory/develop/scenario-spa-acquire-token.md

@@ -8,10 +8,12 @@ manager: celestedg
 ms.service: active-directory
 ms.subservice: B2B
 ms.topic: how-to
-ms.date: 03/02/2021
+ms.date: 11/07/2022
 ms.author: mimart
-ms.custom: engagement-fy23, "it-pro"
+ms.custom: engagement-fy23, it-pro
 ms.collection: M365-identity-device-management
+
+# Customer intent: As a tenant administrator, I want to create custom attributes for the self-service sign-up user flows.
 ---
 
 # Define custom attributes for user flows
@@ -53,4 +55,5 @@ Once you've created a new user using a user flow that uses the newly created cus
 
 ## Next steps
 
-[Add a self-service sign-up user flow to an app](self-service-sign-up-user-flow.md)
+- [Add a self-service sign-up user flow to an app](self-service-sign-up-user-flow.md)
+- [Customize the user flow language](user-flow-customize-language.md)