How to restrict APIs to be allowed to be called by other Apigee APIs only?

[joshuacarino]

How do I make certain APIs be accessible by other Apigee APIs only?.

I'm currently doing this by checking whether if the proxy.url value is localhost and whether of the port is 8998.

But it turns out, across multiple request of the same payload, it would randomly change from localhost to the actual domain of the API as could be seen in the screenshot below.

Any other variable I could use to know that the API came from within Apigee?

Can I use this flow variable virtualhost.ip instead ?. Does the value 127.0.0.1 mean that the API call came from within apigee?. TIA.

Also, I can't quite determine to use this or not as I cant see this flow variable in the documentation here.

Or is there any other flow variable other than this that could be used for such purposes?.

[#2]

you can set the access control policy for the message processors or LB if LB is there in front of your router, then only those requests will be passed. Another thing is you can track only the client IP or forwarded-for header values and implement logic to allow those only.

[dchiesa1]

@arghya das described how to do this a long time ago.

The approach he described here, still works! Check it out.

[joshuacarino]

I have already followed this and is currently implemented in our proxies. However, I have the same concern as that guy @ozanseymen on that thread. As the x-forwarder-for could be changed and if someone discovered the dummy domain, they could still access the internal API aint it?, I'm not well versed into security, but knowing this I implemented a 2nd layer of validation. Hence, as an a secondary measure to block non-internal API calls, I also resorted to validating the IP of the request where it came from, since if the request came locally or from within Apigee, it would have a domain of localhost, to which I found out recently was not always the case.

At the moment, I am validating it using the flow variable virtualhost.ip, which has a value of 127.0.0.1 and doesn't change across multiple request and not changing even if I change the x-forwarder-for variable. And it would also change if the API call came externally or from not within Apigee Edge. Hence it works for now as I wanted it too. My question is, can this variable be used for such purposes?, and how is this value derived?, as I can't see it in the documentation.

My way of validaton using that virtualhost.ip actually almost doesn't make use of the access control policy as this initial validation would always validate to true or false as I want it. Although the AccessControl policy does the job too, I',m just a wee bit concern with regards to its security.

If any, the validation of the virtualhost.ip for me is a much cleaner way of knowing whether if the API call came internally as I just have to use one RaiseFault policy and place it on all internal APIs. Although I still have the implementation of that on on the link as a 2nd layer of security/validation. Will this implementation be okay for the purpose I want it to?. TIA.

[dchiesa1]

if someone discovered the dummy domain, they could still access the internal API aint it?

Yes, that's true.

At the moment, I am validating it using the flow variable virtualhost.ip, which has a value of 127.0.0.1 and doesn't change across multiple request a.... Hence it works for now as I wanted it too. My question is, can this variable be used for such purposes?, and how is this value derived?, as I can't see it in the documentation.

If it isn't documented, then it isn't supported, and is subject to change. Unfortunately.

My way of validaton using that virtualhost.ip actually almost doesn't make use of the access control policy as this initial validation would always validate to true or false as I want it.

I think the AccessControl policy in Arghya's example was for convenience and illustration. It's not a necessary part of the system. The key is the secret domain name.

If any, the validation of the virtualhost.ip for me is a much cleaner way of knowing whether if the API call came internally as I just have to use one RaiseFault policy and place it on all internal APIs. Although I still have the implementation of that on on the link as a 2nd layer of security/validation. Will this implementation be okay for the purpose I want it to?.

I agree, the way you are using virtualhost.ip is clear and clean. That variable is probably used internally by Apigee, and therefore is not likely to change, but if it is not publicly documented, then you cannot count on that. If it's not part of the publicly-documented , supported interface presented by Apigee, then it may change. You could raise a ticket with Apigee Support to request that Apigee document (and implicitly support) this variable. If the Product Managers agree to that, then it would solve your problem. That may take some time, though, if they agree at all. @srinandans@google

In the meantime, I still think Arghya's approach is solid.