[CA API Gateway] Response’s authentication headers transmission with Route via HTTP(S)

[Legacy User]

Hello,
We are using CA API Gateway product in version 9.2.00 and encounter the following problem.
Building a service configuration, the policy assertion “Route via HTTP” was embedded in a “At least one assertion must evaluate to true” to be able to trap errors and process/log them:

The backend service (destination of Route via HTTP) uses Negotiate/NTLM authentication protocol from the request.

Using this configuration, when the first request is sent from third part application, the request is correctly sent to the backend. But the response with code 401 sent back from the gateway to the third part application does not contains the “WWW-Authenticate: Negotiate” and “WWW-Authenticate: NTLM” headers used to indicate the authentication protocol.

Using the debugger, “WWW-Authenticate” headers are not contained in the response header field (only user access information and URLs are hidden in the following capture):

Is there a way to transmit these headers and authentication information between the backend service response and the gateway response to third application?
If this is not the possible, how can we process such case (request authentication transmission and error handling)? What are the best practices and do we respect them?

 

Regards.

[Stephen Hughes]

By default the HTTP Routing assertion will attempt to act against any 400+ Error Code unless otherwise specified. To change the behavior, set the "Never fail as long as target returns an answer" radio button on the HTTP Routing Assertion -> Other tab.

 

 

Sincerely,

 

Stephen Hughes

Director, CA Support

[Legacy User]

Hi Stephen, 

 

Thank you for your answer. Actually this option was already check as per your screenshot, so it appears that the same behavior happens.

[Zhijun He]

Could you show the settings of Headers tab? ensure the "Pass through only certain response headers" option is unchecked.

If it's already unchecked, then it seems the backend doesn't really return the required headers. You can verify by running curl command directly to backend with -v flag to check the response headers.

[Legacy User]

Yes the option is unchecked for both request and response headers 

[thomas.brckl]

Hello,

As Emmanuel.Champommier said, we already are in this configuration.

Here is a description of the different tests we made. In each case, the configuration of the “Route via HTTP” assertion is the following:

• Authentication: Use http Credentials from Request
• Headers: Nothing checked
• HTTP: Use Keep-Alive
• Proxy: Do not use an HTTP proxy
• Other:
  • Request WS-Security Header Handling: Don’t modify the request Security header
  • Assertion Outcome: Never fail as long as target returns an answer

 

Test 1: Direct call: Result is OK

The service is responding correctly with the authentication process (two 401 results and one 200 result).

 

Test 2: Including the “Route via HTTP” in an “Handle Errors” assertion: Result is OK

In this case, the HTTP authentication is processed correctly, with 401 result codes and WWW-Authenticate headers transmission between CA API Gateway and client application (checked using Fiddler proxy):

==> Problem: When the “Route via HTTP” returns an error (401 for authentication for example), the service execution process is automatically stopped right after the assertion, and then some actions are not executed (logs, etc)

 

Test 3: Including the “Route via HTTP” in a “At least one assertion must evaluate to true” and with an error processing action after: Result is KO

In this case, WWW-Authenticate headers are missing in the response to the client application, while response from backend to gateway is correct:

==> Errors returned by “Route via HTTP” are intercepted correctly, but it seems the error response from gateway to client in this case does not contains the response from backend to gateway headers.

 

Is there a way to catch all the “Route via HTTP” errors, and then access and return the full content of the response from backend? Are we treating our log/error problem the right way?

[Zhijun He]

Do you have "Customize error response" assertion in your policy?

You might attach your policy if you don't mind, but it might be better to open a support ticket to investigate your policy, rather than do it on a public forum.

[Stephen Hughes]

Just wrapping up this post based on work done through the case. The end resolution was the combination of
- the setting "Use HTTP Credentials from Request"
- The addition other assertions inside the "At least one..."

In this case you are running into the exception of the "Never fail as long as target returns an answer" setting. Which means, the route assertion would fail and therefore the results of other assertions would overwrite the response from the backend.
To prevent this 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}).
(See https://docops.ca.com/ca-api-gateway/9-2/en/policy-assertions/assertion-palette/message-routing-assertions/route-via-http-s-assertion)

 

Sincerely,

 

Stephen Hughes

CA Support