Layer7 API Management

Currently we are using a route via HTTP assertion from our ca-api-gateway to communicate with an external PDP system which is also on a ca-api-gateway.

The external PDP system  is migrating from their ca-api-gateway to a F5 Big-IP platform.

Due to the above change, our route assertion is failing to communicate with external PDP.

The call to F5 now seems to be doing multiple redirects (302's) and also setting and using cookie to authenticate against redirected endpoints at F5.

Below are the two cURL commands before and after the the external PDP migration which are working and returning results:

L7 API Gateway to L7 API Gateway:

curl -X POST https://<EXT-URL> --cert <CERT> --key <KEY> -H "Content-Type: application/xacml/json" --data "@test.json"

L7 API Gateway to F5:

curl -X POST https://<NEW_EXT-URL> --cookie-jar cookie-jar --post302 --location -H "Clientless-Mode: 1" -H "Content-Type: application/xacml/json" --cert <CERT> --key <KEY> --data "@test.json"

External PDP now being on F5 is forcing us to use "--cookie-jar cookie-jar --post302 --location -H "Clientless-Mode: 1" additional options on a cURL to get results.

My question is, what changes do I need to make or translate those additional options to my route via HTTP assertion in the policy so I can make a successful call to external PDP from our L7 API Gateway?

 Thanks!

-arun

Hello Arun,

You're likely having a problem with the HTTP route assertions Follow Redirects behavior. It will only follow redirects when the request method is GET. It will not follow redirects when the request method is POST like in your example. However, you can handle the latter in policy. Here's a very basic example.

I have two backends, Backend 1 and Backend 2, and a service, FollowRedirect, that will be redirected from one (i.e. Backend 1) to the other (i.e. Backend 2):

The FollowRedirect service policy looks like so:

If I make a curl request to the service with a GET (i.e. no data which would turn it into a POST), then the first route assertion handles the redirect from Backend 1 to Backend 2 and here is the response I get back from Backend 2:

If I make a curl request to the service with a POST (i.e. by sending data), then the first route assertion does not handle the redirect from Backend 1 to Backend 2, and the subsequent policy detects this a posts the original request to the redirect location.  Here is the response I get back from Backend 2:

Currently we are using a route via HTTP assertion from our ca-api-gateway to communicate with an external PDP system which is also on a ca-api-gateway.

The external PDP system  is migrating from their ca-api-gateway to a F5 Big-IP platform.

Due to the above change, our route assertion is failing to communicate with external PDP.

The call to F5 now seems to be doing multiple redirects (302's) and also setting and using cookie to authenticate against redirected endpoints at F5.

Below are the two cURL commands before and after the the external PDP migration which are working and returning results:

L7 API Gateway to L7 API Gateway:

curl -X POST https://<EXT-URL> --cert <CERT> --key <KEY> -H "Content-Type: application/xacml/json" --data "@test.json"

L7 API Gateway to F5:

curl -X POST https://<NEW_EXT-URL> --cookie-jar cookie-jar --post302 --location -H "Clientless-Mode: 1" -H "Content-Type: application/xacml/json" --cert <CERT> --key <KEY> --data "@test.json"

External PDP now being on F5 is forcing us to use "--cookie-jar cookie-jar --post302 --location -H "Clientless-Mode: 1" additional options on a cURL to get results.

My question is, what changes do I need to make or translate those additional options to my route via HTTP assertion in the policy so I can make a successful call to external PDP from our L7 API Gateway?

 Thanks!

-arun

Thanks Ben for your quick turnaround!

So, I scrutinized the request & response using cURL against F5 and found out that F5 doing 302 redirections 3 times and setting 3 types of cookies each time where only one session cookie is not changing throughout and the other two are.

It would have been easy if L7 Gateway would have been handling these 302's automatically with few configurations settings instead of us writing code to handle multiple redirections & cookie manipulations. 

Based on your reply, it seems we don't have a choice here and have to add additional code to handle the scenario?

My follow up question would be, if we code for handling these new redirections and cookies, do we have to change the code if F5 changes to making 3+ redirections or add a new type of cookie or there is a way to loop thru all redirections?

Thanks!

-arun

Hello Arun,

You're likely having a problem with the HTTP route assertions Follow Redirects behavior. It will only follow redirects when the request method is GET. It will not follow redirects when the request method is POST like in your example. However, you can handle the latter in policy. Here's a very basic example.

I have two backends, Backend 1 and Backend 2, and a service, FollowRedirect, that will be redirected from one (i.e. Backend 1) to the other (i.e. Backend 2):

The FollowRedirect service policy looks like so:

If I make a curl request to the service with a GET (i.e. no data which would turn it into a POST), then the first route assertion handles the redirect from Backend 1 to Backend 2 and here is the response I get back from Backend 2:

If I make a curl request to the service with a POST (i.e. by sending data), then the first route assertion does not handle the redirect from Backend 1 to Backend 2, and the subsequent policy detects this a posts the original request to the redirect location.  Here is the response I get back from Backend 2:

Currently we are using a route via HTTP assertion from our ca-api-gateway to communicate with an external PDP system which is also on a ca-api-gateway.

The external PDP system  is migrating from their ca-api-gateway to a F5 Big-IP platform.

Due to the above change, our route assertion is failing to communicate with external PDP.

The call to F5 now seems to be doing multiple redirects (302's) and also setting and using cookie to authenticate against redirected endpoints at F5.

Below are the two cURL commands before and after the the external PDP migration which are working and returning results:

L7 API Gateway to L7 API Gateway:

curl -X POST https://<EXT-URL> --cert <CERT> --key <KEY> -H "Content-Type: application/xacml/json" --data "@test.json"

L7 API Gateway to F5:

curl -X POST https://<NEW_EXT-URL> --cookie-jar cookie-jar --post302 --location -H "Clientless-Mode: 1" -H "Content-Type: application/xacml/json" --cert <CERT> --key <KEY> --data "@test.json"

External PDP now being on F5 is forcing us to use "--cookie-jar cookie-jar --post302 --location -H "Clientless-Mode: 1" additional options on a cURL to get results.

My question is, what changes do I need to make or translate those additional options to my route via HTTP assertion in the policy so I can make a successful call to external PDP from our L7 API Gateway?

 Thanks!

-arun

Hello @Arun Addepalli,

I don't disagree, but currently the HTTP route assertion will only optionally handle HTTP 302 redirects for GET calls. This probably comes from the fact that HTTP 1.0 appears to not have supported POST redirects at all, and though HTTP 1.1 does, it's a security risk and it's recommended to use HTTP 307 replies with specific user agent behavior expectations instead. In any case, I've added support for POST redirects to the gateway backlog for future consideration.

Yes. For now, this is what must be done.

Here is another basic example that uses looping to efficiently handle multiple redirects with an upper limit that you can control (attached as a Graphman bundle, redirect-example-bundle.json, that can be imported to a test gateway using Graphman). It includes the contents of the Redirect folder, including the FollowRedirect encapsulated assertion.

The test API controls the upper limit of the for each loop on line 6, and calls the FollowRedirect encapsulated assertion on line 10:

The FollowRedirect encapsulated assertion is very simple and is only used to provide some response message isolation to avoid current limitations with writing to an existing response message inside of a loop in policy:

You will likely need to add additional policy to propagate headers and cookies as might be necessary for you use case.

Thanks Ben for your quick turnaround!

So, I scrutinized the request & response using cURL against F5 and found out that F5 doing 302 redirections 3 times and setting 3 types of cookies each time where only one session cookie is not changing throughout and the other two are.

It would have been easy if L7 Gateway would have been handling these 302's automatically with few configurations settings instead of us writing code to handle multiple redirections & cookie manipulations. 

Based on your reply, it seems we don't have a choice here and have to add additional code to handle the scenario?

My follow up question would be, if we code for handling these new redirections and cookies, do we have to change the code if F5 changes to making 3+ redirections or add a new type of cookie or there is a way to loop thru all redirections?

Thanks!

-arun

Hello Arun,

You're likely having a problem with the HTTP route assertions Follow Redirects behavior. It will only follow redirects when the request method is GET. It will not follow redirects when the request method is POST like in your example. However, you can handle the latter in policy. Here's a very basic example.

I have two backends, Backend 1 and Backend 2, and a service, FollowRedirect, that will be redirected from one (i.e. Backend 1) to the other (i.e. Backend 2):

The FollowRedirect service policy looks like so:

If I make a curl request to the service with a GET (i.e. no data which would turn it into a POST), then the first route assertion handles the redirect from Backend 1 to Backend 2 and here is the response I get back from Backend 2:

If I make a curl request to the service with a POST (i.e. by sending data), then the first route assertion does not handle the redirect from Backend 1 to Backend 2, and the subsequent policy detects this a posts the original request to the redirect location.  Here is the response I get back from Backend 2:

Currently we are using a route via HTTP assertion from our ca-api-gateway to communicate with an external PDP system which is also on a ca-api-gateway.

The external PDP system  is migrating from their ca-api-gateway to a F5 Big-IP platform.

Due to the above change, our route assertion is failing to communicate with external PDP.

The call to F5 now seems to be doing multiple redirects (302's) and also setting and using cookie to authenticate against redirected endpoints at F5.

Below are the two cURL commands before and after the the external PDP migration which are working and returning results:

L7 API Gateway to L7 API Gateway:

curl -X POST https://<EXT-URL> --cert <CERT> --key <KEY> -H "Content-Type: application/xacml/json" --data "@test.json"

L7 API Gateway to F5:

curl -X POST https://<NEW_EXT-URL> --cookie-jar cookie-jar --post302 --location -H "Clientless-Mode: 1" -H "Content-Type: application/xacml/json" --cert <CERT> --key <KEY> --data "@test.json"

External PDP now being on F5 is forcing us to use "--cookie-jar cookie-jar --post302 --location -H "Clientless-Mode: 1" additional options on a cURL to get results.

My question is, what changes do I need to make or translate those additional options to my route via HTTP assertion in the policy so I can make a successful call to external PDP from our L7 API Gateway?

 Thanks!

-arun

I suspect that Ben's is the better suggestion, however in trying to better understand this issue, I found the writeup on the Wikipedia page enlightening: https://en.wikipedia.org/wiki/HTTP_302

Apparently, because people wanted to maintain HTTP/1.0 compatibility and support the 302 redirects, they actually modified the HTTP/1.1 spec to allow rewriting the PUT to a GET:

https://datatracker.ietf.org/doc/html/rfc7231:

And in section 6.4.3,  "302 Found":

Not sure that this will work in your use case... but I believe it would be entirely allowed by the HTTP specifications to simply changing the PUT request to GET before routing.  Of course the backend may not like that?

Hello @Arun Addepalli,

I don't disagree, but currently the HTTP route assertion will only optionally handle HTTP 302 redirects for GET calls. This probably comes from the fact that HTTP 1.0 appears to not have supported POST redirects at all, and though HTTP 1.1 does, it's a security risk and it's recommended to use HTTP 307 replies with specific user agent behavior expectations instead. In any case, I've added support for POST redirects to the gateway backlog for future consideration.

Yes. For now, this is what must be done.

Here is another basic example that uses looping to efficiently handle multiple redirects with an upper limit that you can control (attached as a Graphman bundle, redirect-example-bundle.json, that can be imported to a test gateway using Graphman). It includes the contents of the Redirect folder, including the FollowRedirect encapsulated assertion.

The test API controls the upper limit of the for each loop on line 6, and calls the FollowRedirect encapsulated assertion on line 10:

The FollowRedirect encapsulated assertion is very simple and is only used to provide some response message isolation to avoid current limitations with writing to an existing response message inside of a loop in policy:

You will likely need to add additional policy to propagate headers and cookies as might be necessary for you use case.

Thanks Ben for your quick turnaround!

So, I scrutinized the request & response using cURL against F5 and found out that F5 doing 302 redirections 3 times and setting 3 types of cookies each time where only one session cookie is not changing throughout and the other two are.

It would have been easy if L7 Gateway would have been handling these 302's automatically with few configurations settings instead of us writing code to handle multiple redirections & cookie manipulations. 

Based on your reply, it seems we don't have a choice here and have to add additional code to handle the scenario?

My follow up question would be, if we code for handling these new redirections and cookies, do we have to change the code if F5 changes to making 3+ redirections or add a new type of cookie or there is a way to loop thru all redirections?

Thanks!

-arun

Hello Arun,

You're likely having a problem with the HTTP route assertions Follow Redirects behavior. It will only follow redirects when the request method is GET. It will not follow redirects when the request method is POST like in your example. However, you can handle the latter in policy. Here's a very basic example.

I have two backends, Backend 1 and Backend 2, and a service, FollowRedirect, that will be redirected from one (i.e. Backend 1) to the other (i.e. Backend 2):

The FollowRedirect service policy looks like so:

If I make a curl request to the service with a GET (i.e. no data which would turn it into a POST), then the first route assertion handles the redirect from Backend 1 to Backend 2 and here is the response I get back from Backend 2:

If I make a curl request to the service with a POST (i.e. by sending data), then the first route assertion does not handle the redirect from Backend 1 to Backend 2, and the subsequent policy detects this a posts the original request to the redirect location.  Here is the response I get back from Backend 2:

Currently we are using a route via HTTP assertion from our ca-api-gateway to communicate with an external PDP system which is also on a ca-api-gateway.

The external PDP system  is migrating from their ca-api-gateway to a F5 Big-IP platform.

Due to the above change, our route assertion is failing to communicate with external PDP.

The call to F5 now seems to be doing multiple redirects (302's) and also setting and using cookie to authenticate against redirected endpoints at F5.

Below are the two cURL commands before and after the the external PDP migration which are working and returning results:

L7 API Gateway to L7 API Gateway:

curl -X POST https://<EXT-URL> --cert <CERT> --key <KEY> -H "Content-Type: application/xacml/json" --data "@test.json"

L7 API Gateway to F5:

curl -X POST https://<NEW_EXT-URL> --cookie-jar cookie-jar --post302 --location -H "Clientless-Mode: 1" -H "Content-Type: application/xacml/json" --cert <CERT> --key <KEY> --data "@test.json"

External PDP now being on F5 is forcing us to use "--cookie-jar cookie-jar --post302 --location -H "Clientless-Mode: 1" additional options on a cURL to get results.

My question is, what changes do I need to make or translate those additional options to my route via HTTP assertion in the policy so I can make a successful call to external PDP from our L7 API Gateway?

 Thanks!

-arun