JWT Validation

Dynamic configuration no longer fails due to heavy payloads.

Some parsing errors no longer cause the original payload to be returned in the response.

Flex support for Connected Mode.

Introduced support for ES256, ES384, and ES512 signature validation algorithms.

A Cannot parse the token error message was logged with ERROR log level instead of TRACE.

Several logs were moved from DEBUG log level to TRACE.

The JWKS service URL was exposed in the HTTP response from policies.

Introduced the capability to configure timeouts when fetching the JSON web key sets (JWKS) from the service.

Implemented a retry mechanism for failed JWKS fetches from the service.

Added OAS 3.0 code snippet in the policy YAML file.

Error handling responses revised for WSDL APIs to be compliant with SOAP 1.1 and 1.2.

Performance improvements are introduced to the header manipulation engine.

Several performance improvements are introduced in error handling.

After a policy was applied, HTTP headers did not follow the RFC 2616 requirement of case-sensitivity:

An error occurred when handling invalid header values of the Basic Authentication policy.

When requests are made to the protected API endpoint with the Client ID Enforcement policy that does not include the client ID and/or secret, a log entry is now created with the details. However, this logging occurs only when you have specified the Debug level in the log4j settings.

An error occurs in Mule runtime engine (Mule) versions 4.1.1, 4.1.2, 4.1.3, and 4.1.4 when a policy is deployed to applications that have the mule-secure-configuration-property-module plugin configured. To resolve this issue, upgrade the specified plugin in the application to version 1.1.0.

When JWT policy is applied to a flow running in Mule 4.2.0 or 4.2.1 Mule and the flow contains an operation that runs on a CPU_INTENSIVE thread, like ee:transform, the flow stops responding under load. To resolve the issue, apply a patch to the Mule runtime engine.

Introduced support to encrypt sensitive information related to the policy. The Mule version must be properly configured and must support encryption. Encryption is supported starting with Mule v4.2.0.

Serveral performance improvements are introduced in this release.

When JWT policy is applied to a flow running in Mule 4.2.0 or 4.2.1 Mule and the flow contains an operation that runs on a CPU_INTENSIVE thread, like ee:transform, the flow stops responding under load. To resolve the issue, apply a patch to the Mule runtime engine. == 1.0.2

When JWT policy is applied to a flow running in Mule 4.2.0 or 4.2.1 Mule and the flow contains an operation that runs on a CPU_INTENSIVE thread, like ee:transform, the flow stops responding under load. To resolve the issue, apply a patch to the Mule runtime engine.

When JWT policy is applied to a flow running in Mule 4.2.0 or 4.2.1 Mule and the flow contains an operation that runs on a CPU_INTENSIVE thread, like ee:transform, the flow stops responding under load. To resolve the issue, apply a patch to the Mule runtime engine.

When JWT policy is applied to a flow running in Mule 4.2.0 or 4.2.1 Mule and the flow contains an operation that runs on a CPU_INTENSIVE thread, like ee:transform, the flow stops responding under load. To resolve the issue, apply a patch to the Mule runtime engine.