[APIM] Release notes 46 updates

Author: dlepow

articles/api-management/api-management-subscriptions.md

@@ -5,8 +5,8 @@ services: api-management
 author: dlepow
 
 ms.service: azure-api-management
-ms.topic: conceptual
-ms.date: 08/02/2023
+ms.topic: concept-article
+ms.date: 08/30/2024
 ms.author: danlep
 ms.custom: engagement-fy23
 ---
@@ -142,6 +142,8 @@ When API Management receives an API request from a client with a subscription ke
 
     If a valid key for an active subscription at an appropriate scope is provided, access is allowed. Policies are applied depending on the configuration of the policy definition at that scope.
 
+1. Check if the API requires a subscription. If the API doesn't require a subscription, handle the request in the context of the API and operation.
+
 1. Otherwise, access is denied (401 Access denied error).
 
 ### API request without a subscription key
@@ -160,19 +162,20 @@ The following table summarizes how the gateway handles API requests with or with
 |All products assigned to API require subscription  |API requires subscription  |API call with subscription key  |API call without subscription key  | Typical scenarios |
 |---------|---------|---------|---------|----|
 |✔️     | ✔️     | Access allowed:<br/><br/>• Product-scoped key<br/>• API-scoped key<br/>• All APIs-scoped key<br/>• Service-scoped key<br/><br/>Access denied:<br/><br/>• Other key not scoped to applicable product or API        | Access denied        | Protected API access using product-scoped or API-scoped subscription  |
-|✔️     |  ❌    | Access allowed:<br/><br/>• Product-scoped key<br/>• API-scoped key<br/>• All APIs-scoped key<br/>• Service-scoped key<br/><br/>Access denied:<br/><br/>• Other key not scoped to applicable product or API        |  Access allowed (API context)   | • Protected API access with product-scoped subscription<br/><br/>• Anonymous access to API. If anonymous access isn’t intended, configure API-level policies to enforce authentication and authorization. |
-|❌<sup>1</sup>     | ✔️    | Access allowed:<br/><br/>• Product-scoped key<br/>• API-scoped key<br/>• All APIs-scoped key<br/>• Service-scoped key<br/><br/>Access denied:<br/><br/>• Other key not scoped to applicable product or API        |    Access allowed (open product context)     | •	Protected API access with API-scoped subscription<br/><br/>•	Anonymous access to API. If anonymous access isn’t intended, configure with product policies to enforce authentication and authorization  |
-|❌<sup>1</sup>     |  ❌      | Access allowed:<br/><br/>• Product-scoped key<br/>• API-scoped key<br/>• All APIs-scoped key<br/>• Service-scoped key<br/><br/>Access denied:<br/><br/>• Other key not scoped to applicable product or API        | Access allowed (open product context)        | Anonymous access to API. If anonymous access isn’t intended, configure with product policies to enforce authentication and authorization  |
+|✔️     |  ❌    | Access allowed:<br/><br/>• Product-scoped key<br/>• API-scoped key<br/>• All APIs-scoped key<br/>• Service-scoped key<br/>• Other key not scoped to applicable API        |  Access allowed (API context)   | • Protected API access with product-scoped subscription<br/><br/>• Anonymous access to API. If anonymous access isn't intended, configure API-level policies to enforce authentication and authorization. |
+|❌<sup>1</sup>     | ✔️    | Access allowed:<br/><br/>• Product-scoped key<br/>• API-scoped key<br/>• All APIs-scoped key<br/>• Service-scoped key<br/>• Other key not scoped to applicable product        |    Access allowed (open product context)     | •	Protected API access with API-scoped subscription<br/><br/>•	Anonymous access to API. If anonymous access isn't intended, configure with product policies to enforce authentication and authorization  |
+|❌<sup>1</sup>     |  ❌      | Access allowed:<br/><br/>• Product-scoped key<br/>• API-scoped key<br/>• All APIs-scoped key<br/>• Service-scoped key<br/><br/>• Other key not scoped to applicable product or API        | Access allowed (open product context)        | Anonymous access to API. If anonymous access isn't intended, configure with product policies to enforce authentication and authorization  |
 
 <sup>1</sup> An open product exists that's associated with the API. 
 
 ### Considerations
 
 -	API access in a product context is the same, whether the product is published or not. Unpublishing the product hides it from the developer portal, but it doesn’t invalidate new or existing subscription keys.
--	Even if a product or API doesn't require a subscription, a valid key from an active subscription that enables access to the product or API can still be used.
+-	If a product associated with the API or the API doesn't require a subscription, any subscription key may be passed in the request and will be ignored.
 -	API access "context" means the policies and access controls that are applied at a particular scope (for example, API or product).
 
-## Next steps
+## Related content
+
 Get more information on API Management:
 
 + Learn how API Management [policies](set-edit-policies.md#configure-policies-at-different-scopes) get applied at different scopes.

articles/api-management/validate-content-policy.md

@@ -6,7 +6,7 @@ author: dlepow
 
 ms.service: azure-api-management
 ms.topic: article
-ms.date: 07/23/2024
+ms.date: 08/30/2024
 ms.author: danlep
 ---
 
@@ -47,7 +47,7 @@ The policy validates the following content in the request or response against th
     <content-type-map any-content-type-value="content type string" missing-content-type-value="content type string">
         <type from | when="content type string" to="content type string" />
     </content-type-map>
-    <content type="content type string" validate-as="json | xml | soap" schema-id="schema id" schema-ref="#/local/reference/path" action="ignore | prevent | detect" allow-additional-properties="true | false" />
+    <content type="content type string" validate-as="json | xml | soap" schema-id="schema id" schema-ref="#/local/reference/path" action="ignore | prevent | detect" allow-additional-properties="true | false" case-insensitive-property-names="true | false"/>
 </validate-content>
 ```
 
@@ -90,6 +90,7 @@ The policy validates the following content in the request or response against th
 | schema-id | Name of an existing schema that was [added](#schemas-for-content-validation) to the API Management instance for content validation. If not specified, the default schema from the API definition is used. | No | N/A |
 | schema-ref| For a JSON schema specified in `schema-id`, optional reference to a valid local reference path in the JSON document. Example: `#/components/schemas/address`. The attribute should return a JSON object that API Management handles as a valid JSON schema.<br/><br/> For an XML schema, `schema-ref` isn't supported, and any top-level schema element can be used as the root of the XML request or response payload. The validation checks that all elements starting from the XML request or response payload root adhere to the provided XML schema. | No | N/A |
 | allow-additional-properties |  Boolean. For a JSON schema, specifies whether to implement a runtime override of the `additionalProperties` value configured in the schema: <br> - `true`: allow additional properties in the request or response body, even if the JSON schema's `additionalProperties` field is configured to not allow additional properties. <br> - `false`: do not allow additional properties in the request or response body, even if the JSON schema's `additionalProperties` field is configured to allow additional properties.<br/><br/>If the attribute isn't specified, the policy validates additional properties according to configuration of the `additionalProperties` field in the schema. | No |   N/A  |
+| case-insensitive-property-names | Boolean. For a JSON schema, specifies whether to compare property names of JSON objects without regard to case. <br> - `true`: compare property names case insensitively. <br> - `false`: compare property names case sensitively. | No | false |
 
 [!INCLUDE [api-management-validation-policy-actions](../../includes/api-management-validation-policy-actions.md)]
 

articles/api-management/validate-jwt-policy.md

@@ -6,7 +6,7 @@ author: dlepow
 
 ms.service: azure-api-management
 ms.topic: article
-ms.date: 07/23/2024
+ms.date: 08/30/2024
 ms.author: danlep
 ---
 
@@ -119,7 +119,7 @@ The `validate-jwt` policy enforces existence and validity of a supported JSON we
 * The policy supports both symmetric and asymmetric signing algorithms: 
     * **Symmetric** - The following encryption algorithms are supported: A128CBC-HS256, A192CBC-HS384, A256CBC-HS512.
     	* If used in the policy, the key must be provided inline within the policy in the Base64-encoded form.
-    * **Asymmetric** - The following encryption algortithms are supported: PS256, RS256, RS512. 
+    * **Asymmetric** - The following encryption algortithms are supported: PS256, RS256, RS512, ES256. 
     	* If used in the policy, the key may be provided either via an OpenID configuration endpoint, or by providing the ID of an uploaded certificate (in PFX format) that contains the public key, or the modulus-exponent pair of the public key.
 * To configure the policy with one or more OpenID configuration endpoints for use with a self-hosted gateway, the OpenID configuration endpoints URLs must also be reachable by the cloud gateway.
 * You can use access restriction policies in different scopes for different purposes. For example, you can secure the whole API with Microsoft Entra authentication by applying the `validate-jwt` policy on the API level, or you can apply it on the API operation level and use `claims` for more granular control.