​How to whitelist Apigee Organization?.

[joshuacarino]

So I used proxy chaining in Apigee. And I see that I could still call that API externally. Is there a way to restrict access to our API by allowing only Apigee/our proxy to call it?. I don't know what I.P address to use to allow my Externally Exposed API to be able to used the internal APIs.

Given I have an organization endpoint like

alphabet-google-dev.apigee.net

alphabet-google-sit.apigee.net

alphabet-google-uat.apigee.net

alphabet-google-dr.apigee.net

alphabet-google-production.apigee.net

[robert · Accepted solution]

Hi @Joshua Cariño

Yes, you can do it. If I understand you correctly, you only want to allow requests to a proxy from within Apigee Edge itself. If so, just check the proxy request IP address. If it's from within Apigee, it will be 127.0.0.1

There are a few ways to accomplish this task but a quick and easy way is to add a raise fault policy as a first step and then set a condition on it. This way it will fire if the call is not local. Something like: proxy.client.ip NotEquals "127.0.0.1"

Hope that helps!

[joshuacarino]

Hi,
Thanks for the reply.

Yeap, exactly.

I have already done what this on another question said. By Proxy Chaining and Adding an Access Contr...

However, after doing all that, my concern with using proxy.client.ip (as you suggested too) is that it could be bypassed if someone knew what the mock ip is being used by the API by just adding that IP Address in the X-Forwarder-For of the request. Someone raised this question from the link above too.

So I'm thinking, Instead of proxy.client.ip, can I use the Flow Variable proxy.url to do the final validation that the request indeed came from within our Apigee organization?. Is this the flow variable that stores the IP address of the sender of the request?.

[robert]

per the docs, that field is set by Apigee:

The X-Forwarded-For address of the inbound call, which is the IP address Edge received from the last external TCP handshake. This could be the calling client or a load balancer.

[joshuacarino]

Yes, that's my concern. That what if the last sender knew the mock IP Address we use to in the AccessControl. (As is the concern in the question I linked above) Modifying the X-Forwarded-For in the request will still give it access to the API. I tried it already, and it worked even though the original request came externally.

[robert]

ok. try this variable then: "client.ip"

Also, the variable "virtualhost.port" will be 8998 when it is coming from within Edge. To the best of my knowledge, that port should only be set to that value when localhost is used. Try those out with your hack scenario and post back here please.

[robert]

Just to be clear, replace proxy.client.ip with just client.ip. That variable is supposed to be the actual client connection IP.

[joshuacarino]

So I was checking the Flow Variables in Apigee. And Found that yes, client.ip could work too, but if I have a proxy, this may probably still be overridden by the proxy redirecting the request (haven't tested that flow variable yet). As it say, this is the address of the sender of the request to the apigee router. To which I understood as still like how X-Forwarder-FOr works. Instead, I used the flow variable I found on the Trace log named

proxy.url

as it says in the Documentation that this

"Gets the complete URL associated with the proxy request received by the ProxyEndpoint, including any query parameters present. "

even better I think is that it says that

Note that the host in proxy.url is the router host, not the host used in the original request.

From what I understand is that this is the last URL / actual IP address of the one that sent the request to our Internal non directly exposed API. Just about what I'm looking for, as I want to validate whether if the call actually came from within our Proxy / Locally within the Organization.

I then just used this Regular expression

^(https?|http?):\/\/(localhost:)\d+[-a-zA-Z0-9+&@\/%?=~_|!:,.;]*[-a-zA-Z0-9+&038;038;@\/%=~_|]

to check whether if the API call came locally and with the host and port you told me about. This is in a shared flow with a raise fault. So when this is not met, a raise fault would be triggered.

I then put this in the pre-flow, just before the Access Control policy, and now this Shared flow is triggered every time our internal API is called externally. The Access Control is not being triggered now since I placed it after the Raise Fault of the Shared flow, but I left it there just in case it bypassed my initial validation.


This should prolly work as intended now then right?. Pls. correct me I made mistakes in the implementation and the goal of actually blocking non Proxy or non Local call.

[robert]

That works as well. As long as you tested that regex and confirmed the pattern works, you are good!