Issue:

The Decode JSON Web Token Assertion does not fail when an invalid JSON Web Token (JWT) signature is detected. Although this behavior is by design, some users may construct policies assuming that an invalid JWT signature causes the assertion to fail. (DE292005)

Workaround:

To ensure that policy processing stops when an invalid JWT signature is detected, place a Compare Expression Assertion immediately following the Decode JSON Web Token Assertion and have it test for

${<prefix>.valid}

= true. If the JWT signature fails,

${<prefix>.valid}

returns 'false' causing the Compare Expression Assertion to fail.

The instructions below describe how to identify all occurrences of the Decode JSON Web Token assertion, how to configure the Compare Expression assertion and where to place it in your policy.

Do the following steps to identify all policies that contain a Decode JSON Web Token Assertion:

Configure the Compare Expression Assertion to test whether the

${

<prefix>

.valid}

context variable is 'true', where the "<prefix>" is defined in the Decode JSON Web Token Assertion. For example, if the prefix is 'output', you define the comparison: 

${output.valid} == true

. The properties dialog should look like this:

Where you place the Compare Expression Assertion depends on the policy logic in use at the branch. These are the main scenarios:

For detailed instructions on how to modify your OAuth Took Kit policies, please refer to "Release Notes" in the CA API Management OAuth Toolkit online documentation.

When you generate a report, you may get an error message under

Generated Reports

,

Status=FAILED

,

Status Detail=Error creating report style template

. (EM-1040)

Prior to Release 8.3, any transfer-encoding header added to the response by a policy is ignored if the

API Gateway

 does its own response transfer-encoding handling. As of Release 8.3, a policy may perform its own response transfer-encoding handling by encoding the response body and adding the transfer-encoding header. If this header is present in the response after the policy completes, the Gateway's built-in transfer-encoding processing will be suppressed. (SSG-10755)

Some file permissions may not be correctly restored after a Gateway is restored using the

ssgrestore.sh

command, resulting in the Policy Manager being unable to connect to the 

API Gateway

. To correct this, see "Problem: Gateway is not running properly after a restore" in Troubleshoot. (SSG-9735)

The [Other] tab in the HTTP(S) Routing Properties contains the control [

Never fail as long as target returns an answer

]. There is a known issue that can still cause the assertion to fail even when an answer is returned under the following scenario:

To prevent assertion failure in this scenario, use “Specify HTTP Credentials” as the Service Authentication method instead. Specify the username and password as context variables from the request (i.e.,

${request.username}

,

${request.password}

). (SSG-5372)

There is a known issue in the

Route via SSH

assertion that causes the connection timeout to be twice as long as the value specified in the assertion when the SFTP protocol is selected. (SSG-5116)

Customer-developed Custom Assertions created in version 7.1. may fail to load after upgrading to version 8.3 of the CA API Gateway due to a change in the Custom Assertion SDK, causing an “Unknown assertion: CustomAssertion” error to occur.

For detailed information about this issue, see the “Important Note” in the document 

Creating CA API Gateway Custom Assertions, v2.2

.

Deleting an OAuth policy that contains policy fragments serving as backing policies for encapsulated assertions will trigger dependency errors in the Policy Manager. These errors cannot be acknowledged in bulk nor can the deletion be cancelled. For workarounds to avoid this, see "Problem: Deleting OAuth policy creates dependency errors" in Troubleshoot. (SSM-5068)

The [Test] button in the JDBC Connection Properties may fail to detect invalid JDBC URLs. This is caused by a problem in a third-party library used by the Gateway.

Workaround:

For MySQL, ensure that the URL is in this format:

Note that if a database is defined, it must be preceded by the '/' character.

The current version of the CA API Gateway does not support the "format" attribute in JSON Schema V2. This may result in dates not being validated correctly, for example.

Workaround: 

If feasible, upgrade to 

CA API Gateway

v9.3, which supports both JSON Schema Validation V2 and V4. The "format" attribute is fully supported when using V4.