Layer7 API Management

Hi there,

for the Route via HTTP(S) assertion one of the default settings is: "Never fail as long as target returns an answer", but based on official CA-documentation there is an exception for 401 HTTP errors in case another default setting "Use HTTP Credentials from Request" is selected. See here under point 3.

As we have currently some issues with such 401 HTTP errors, because they will not passed through to the client, I want to understand the behavior and background of "The assertion may still fail [...]". Also the mentioned workaround is not really helpful and interrupts correct requests, where the credentials are already included. I mean I could implement something like:

• Take the "Authorization" Header and base64 decode its value
• Split it on the ":" and store it into two variables i.e. $username and $password
• Use these variables with the "Specify HTTP Credentials" option

But I would expect that the API GW is already exactly doing this with the default setting. Therefor can someone provide some more details what "may" means and how to prevent this?

Thank you!

Ciao Stefan

Stefan,

In older versions of the gateway, we would not by default transmit the Authorization header through to the back-end so you needed to check the Authentication to send from request. When this occurred it made the Gateway the intermediate client if this was set including "Never fail as long as target returns an answer" so the Gateway assertion would fail.

In versions after 8.2, the default behavior of the HTTP Routing assertion changed so it would pass through all headers if a new HTTP Routing assertion was added to the policy.  If the back-end was set to ask for credentials and "Never fail as long as target returns an answer" was set, the gateway would ask the client calling the gateway for this information and the HTTP Routing Assertion would not fail.

Sincerely,

Stephen Hughes

Director, CA Support

Hi Stephen,

thank you for your answer, but what do you mean with "if a new HTTP Routing assertion was added to the policy"?
Because we are running version 9.1, which should not be affected in general. But maybe some older policies were created in version 8.2 (or lower) and then migrated to 9.1. Should this have an impact? And if yes how can I validate and correct this? Just delete the Routing assertion and insert it again?

Thank you!

Ciao Stefan

Stefan,

If you uncheck the box to only pass through certain request headers will send through all headers from the client including authorization. If you need to remove certain headers include a Manage Properties/Header assertion before the HTTP Routing assertion.

Sincerely,

Stephen Hughes

Director, CA Support

Hi Stephen,

this option is already unchecked in our settings. Here is the XML-part of our assertion:

<?xml version="1.0" encoding="UTF-8"?>
<wsp:Policy xmlns:L7p="http://www.layer7tech.com/ws/policy" xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy">
    <wsp:All wsp:Usage="Required">
        <L7p:HttpRoutingAssertion>
            <L7p:CurrentSecurityHeaderHandling intValue="3"/>
            <L7p:FailOnErrorStatus booleanValue="false"/>
            <L7p:PassthroughHttpAuthentication booleanValue="true"/>
            <L7p:ProtectedServiceUrl stringValue="${wsg.static.backendURI}${REST_PATH}"/>
            <L7p:ProxyPassword stringValueNull="null"/>
            <L7p:ProxyUsername stringValueNull="null"/>
            <L7p:RequestHeaderRules httpPassthroughRuleSet="included">
                <L7p:ForwardAll booleanValue="true"/>
                <L7p:Rules httpPassthroughRules="included">
                    <L7p:item httpPassthroughRule="included">
                        <L7p:Name stringValue="Cookie"/>
                    </L7p:item>
                    <L7p:item httpPassthroughRule="included">
                        <L7p:Name stringValue="SOAPAction"/>
                    </L7p:item>
                </L7p:Rules>
            </L7p:RequestHeaderRules>
            <L7p:RequestParamRules httpPassthroughRuleSet="included">
                <L7p:ForwardAll booleanValue="true"/>
                <L7p:Rules httpPassthroughRules="included"/>
            </L7p:RequestParamRules>
            <L7p:ResponseHeaderRules httpPassthroughRuleSet="included">
                <L7p:ForwardAll booleanValue="true"/>
                <L7p:Rules httpPassthroughRules="included">
                    <L7p:item httpPassthroughRule="included">
                        <L7p:Name stringValue="Set-Cookie"/>
                    </L7p:item>
                </L7p:Rules>
            </L7p:ResponseHeaderRules>
        </L7p:HttpRoutingAssertion>
    </wsp:All>
</wsp:Policy>

When running the Debugger, I see a "httpRouting.reasonCode" with 401, but this will NOT passed through to the client, because the assertion fails and a "Return Template Response to Requestor" will be executed instead.
So still the question, why the Gateway interprets a 401 Response from the backend as failure.

Thank you!

Ciao Stefan

Stefan,

Please change the  Authentication tab from Use HTTP credentials from Request to None (Anonymous).

Sincerely,

Stephen Hughes

Director, CA Support

Regarding the behavior of the HTTP Route assertion with the 401 error, the default is for the policy to fail if the target returns an error status >= 400. You can change this default behavior by changing the 'Assertion Outcome' property of the HTTP Route assertion on the 'Other' tab, as documented here:

Route via HTTP(S) Assertion -- Configuring the [Other] Tab

Hi Stephen,

but what happend with the credentials already included in the request? Will it be ignored/destroyed?

Still fighting to understand the behavoir/idea of this option, especially after your last comment.

Or can you please explain in detail all the steps, which will happen internally in the API-Gateway in regards to these two options?

Thank you!

Ciao Stefan

Stefan,

When the authentication is received as username and password in the Authentication header, the gateway can use this header in the HTTP Basic Assertion and authenticated against an Identity Provider. When this information hits the HTTP Routing assertion if you choose to pass through all headers the Authentication header will then flow to the back end and can be used for authentication. If you choose to flow this back to the client but allowing the HTTP Routing Assertion to not fail as long as its received a response then it will pass back to the client for the back and forth. When you choose to include the Use HTTP credentials from Request option, then the Gateway becomes the client of initiating the authentication so it does not pass back to the user. If you choose that option then you should either remove the Authentication header or select only certain headers to send through on the HTTP Routing assertion.

Sincerely,

Stephen Hughes

Director, CA Support

Hi Stephen,

just to double check that I understand you correctly. With the "None (Anonymous)" option the GW acts totally transparent in regards to authentication, means clients are still able to authenticate against the backend in case the backend requires any kind of authentication and the GW just forwards any related packet/request (in both directions)?
And with any of the other options, the GW takes the role of the Client and authenticates on behalf of it towards the backend with the appropriate values. As a result, any error message during the authentication process will not be forwarded to the client.

If that's right then I got it.

Thank you!

Ciao Stefan

Stefan,

Your summary above is correct. The none option creates more of a true proxy between the client and the back end.

Sincerely,

Stephen Hughes

Director, CA Support