Merge pull request #95563 from ecfan/certs

Update password reqs for client certificate authentication

Author: PRMerger6

articles/logic-apps/logic-apps-custom-api-authentication.md

@@ -294,9 +294,7 @@ For example:
 
 #### Certificate authentication
 
-To validate the incoming requests from your logic app to your web app or API app, 
-you can use client certificates. To set up your code, learn 
-[how to configure TLS mutual authentication](../app-service/app-service-web-configure-tls-mutual-auth.md).
+To validate the incoming requests from your logic app to your web app or API app, you can use client certificates. To set up your code, learn [how to configure TLS mutual authentication](../app-service/app-service-web-configure-tls-mutual-auth.md).
 
 In the **Authorization** section, include these properties:
 
@@ -308,12 +306,12 @@ In the **Authorization** section, include these properties:
 } 
 ```
 
-| Property | Required | Description | 
-| -------- | -------- | ----------- | 
-| type | Yes | The authentication type. For SSL client certificates, the value must be `ClientCertificate`. | 
-| password | Yes | The password for accessing the client certificate (PFX file) | 
-| pfx | Yes | The base64-encoded contents of the client certificate (PFX file) | 
-|||| 
+| Property | Required | Description |
+| -------- | -------- | ----------- |
+| `type` | Yes | The authentication type. For SSL client certificates, the value must be `ClientCertificate`. |
+| `password` | No | The password for accessing the client certificate (PFX file) |
+| `pfx` | Yes | The base64-encoded contents of the client certificate (PFX file) |
+||||
 
 <a name="basic"></a>
 

articles/logic-apps/logic-apps-securing-a-logic-app.md

@@ -31,7 +31,7 @@ Here are the ways that you can secure access to this trigger type:
 
 * [Generate shared access signatures](#sas)
 * [Restrict inbound IP addresses](#restrict-inbound-ip-addresses)
-* [Add Azure Active Directory, OAuth, or other security](#add-authentication)
+* [Add Azure Active Directory OAuth or other security](#add-authentication)
 
 <a name="sas"></a>
 
@@ -161,9 +161,9 @@ If you [automate deployment for logic apps by using Resource Manager templates](
 
 <a name="add-authentication"></a>
 
-### Add Azure Active Directory, OAuth, or other security
+### Add Azure Active Directory OAuth or other security
 
-To add more authorization protocols to your logic app, consider using the [Azure API Management](../api-management/api-management-key-concepts.md) service. This service helps you expose your logic app as an API and offers rich monitoring, security, policy, and documentation for any endpoint. API Management can expose a public or private endpoint for your logic app. You can then use Azure Active Directory, OAuth, certificate, or other security standards for authorizing access to that endpoint. When API Management receives a request, the service sends the request to your logic app, also making any necessary transformations or restrictions along the way. To let only API Management trigger your logic app, you can use your logic app's inbound IP range settings.
+To add more authorization protocols to your logic app, consider using the [Azure API Management](../api-management/api-management-key-concepts.md) service. This service helps you expose your logic app as an API and offers rich monitoring, security, policy, and documentation for any endpoint. API Management can expose a public or private endpoint for your logic app. To authorize access to this endpoint, you can use [Azure Active Directory OAuth](#azure-active-directory-oauth-authentication), [client certificate](#client-certificate-authentication), or other security standards for authorizing access to that endpoint. When API Management receives a request, the service sends the request to your logic app, also making any necessary transformations or restrictions along the way. To let only API Management trigger your logic app, you can use your logic app's inbound IP range settings.
 
 <a name="secure-operations"></a>
 
@@ -359,7 +359,7 @@ Here are some [considerations to review](#obfuscation-considerations) when you u
 
 If you deploy across different environments, consider parameterizing the values in your workflow definition that vary based on those environments. That way, you can avoid hard-coded data by using an [Azure Resource Manager template](../azure-resource-manager/template-deployment-overview.md) to deploy your logic app, protect sensitive data by defining secured parameters, and pass that data as separate inputs through the [template's parameters](../azure-resource-manager/template-parameters.md) by using a [parameter file](../azure-resource-manager/resource-manager-parameter-files.md).
 
-For example, if you authenticate HTTP actions with [Azure Active Directory](#azure-active-directory-oauth-authentication), you can define and secure the parameters that accept the client ID and client secret that are used for authentication. To define these parameters in your logic app, use the `parameters` section in your logic app's workflow definition and Resource Manager template for deployment. To hide parameter values that you don't want shown when editing your logic app or viewing run history, define the parameters by using the `securestring` or `secureobject` type and use encoding as necessary. Parameters that have this type aren't returned with the resource definition and aren't accessible when viewing the resource after deployment. To access these parameter values during runtime, use the `@parameters('<parameter-name>')` expression inside your workflow definition. This expression is evaluated only at runtime and is described by the [Workflow Definition Language](../logic-apps/logic-apps-workflow-definition-language.md).
+For example, if you authenticate HTTP actions with [Azure Active Directory OAuth](#azure-active-directory-oauth-authentication), you can define and secure the parameters that accept the client ID and client secret that are used for authentication. To define these parameters in your logic app, use the `parameters` section in your logic app's workflow definition and Resource Manager template for deployment. To hide parameter values that you don't want shown when editing your logic app or viewing run history, define the parameters by using the `securestring` or `secureobject` type and use encoding as necessary. Parameters that have this type aren't returned with the resource definition and aren't accessible when viewing the resource after deployment. To access these parameter values during runtime, use the `@parameters('<parameter-name>')` expression inside your workflow definition. This expression is evaluated only at runtime and is described by the [Workflow Definition Language](../logic-apps/logic-apps-workflow-definition-language.md).
 
 > [!NOTE]
 > If you use a parameter in a request header or body, that parameter might be visible when you view your logic app's 
@@ -574,7 +574,17 @@ Here are some ways that you can secure endpoints that receive calls or requests
 
 * Add authentication to outbound requests.
 
-  When you work with an HTTP-based trigger or action that makes outbound calls, such as HTTP, HTTP + Swagger, or Webhook, you can add authentication to the request that's sent by your logic app. For example, you can use basic authentication, client certificate authentication, [Active Directory OAuth](../active-directory/develop/about-microsoft-identity-platform.md) authentication, or a managed identity. For more information, see [Add authentication to outbound calls](#add-authentication-outbound) later in this topic.
+  When you work with an HTTP-based trigger or action that makes outbound calls, such as HTTP, HTTP + Swagger, or Webhook, you can add authentication to the request that's sent by your logic app. For example, you can use these authentication types:
+
+  * [Basic authentication](#basic-authentication)
+
+  * [Client certificate authentication](#client-certificate-authentication)
+
+  * [Active Directory OAuth authentication](#azure-active-directory-oauth-authentication)
+
+  * [Managed identity authentication](#managed-identity-authentication)
+  
+  For more information, see [Add authentication to outbound calls](#add-authentication-outbound) later in this topic.
 
 * Restrict access from logic app IP addresses.
 
@@ -654,7 +664,7 @@ If the [Client Certificate](../active-directory/authentication/active-directory-
 |---------------------|-----------------|----------|-------|-------------|
 | **Authentication** | `type` | Yes | **Client Certificate** <br>or <br>`ClientCertificate` | The authentication type to use for Secure Sockets Layer (SSL) client certificates. While self-signed certificates are supported, self-signed certificates for SSL aren't supported. |
 | **Pfx** | `pfx` | Yes | <*encoded-pfx-file-content*> | The base64-encoded content from a Personal Information Exchange (PFX) file |
-| **Password** | `password`| Yes | <*password-for-pfx-file*> | The password for accessing the PFX file |
+| **Password** | `password`| See description | <*password-for-pfx-file*> | The password for accessing the PFX file. <p><p>**Note**: This property value is required when you work in the Logic App Designer and is *not* required when you work in code view. |
 |||||
 
 When you use [secured parameters](#secure-action-parameters) to handle and protect sensitive information, for example, in an [Azure Resource Manager template for automating deployment](../logic-apps/logic-apps-azure-resource-manager-templates-overview.md), you can use expressions to access these parameter values at runtime. This example HTTP action definition specifies the authentication `type` as `ClientCertificate` and uses the [parameters() function](../logic-apps/workflow-definition-language-functions-reference.md#parameters) to get the parameter values: