Can Apigee Edge be used to proxy requests from internal systems to external services?

We want to leverage Apigee Edge for outbound connections, ie we want to be able to send request from the corporate WAN into Apigee Edge, and then use Apigee Edge to proxy requests to external services.

We have been using Edge for inbound connections where in a request from an external client is forwarded to our internal api, and after all processing, the external client is provided with an appropriate response.

Can this process be reversed? ie can apigee be used to forward requests from api's to external service/clients? If yes how can this be achieved?

Thanks,

Vednath

1 7 2,423
7 REPLIES 7

Sure - you can do it.

here's a novel thought: Apigee Edge makes no distinction between "internal clients" and "external clients".

Apigee Edge runs in the cloud, on the internet, and so a request arriving at Edge from an "external client" is indistinguishable from a request arriving at Edge from an "internal client". This distinction is known only to you.

As to how you can achieve what you want, if I understand your question, it seems to be a simple matter of configuring a new proxy, with the appropriate targets pointing to the "external services". Apply the policies you would like, on that proxy, just as you would normally. In fact, it *is* normal. It is not "like normal". This is just standard Apigee Edge proxy design.

This allows you to, for example, mediate internally-originated API request through a proxy, to use a common (corporate-wide?) key or credentials from some external service. Or, you could configure Apigee Edge to act as a cache on an external service that imposes request limits. Or... Well, you get the idea. The possibilities are many.

You will want to think about how to restrict the APIs exposed in Edge for "internal clients" from use by external clients. That is a matter of authentication and authorization - for that you will look to a distinct OAuth token dispensary for the internal clients, relying on the internal or corporate IdP.

I have previously described how to use an LDAP resource for this purpose; but there are myriad other possibilities - mediating between SAML and OAuth, for example. Or, using an OpenID Connect flow, and a JWT for internal users.

Dino, i think the question is more about support of Edge for push technologies like web socket, long-polling, comet etc.. How can that be achived with Edge? I would be interested too.

thanks

I'm not sure about that, even now.

@Dino Let me provide more details to add some context to the question. We have apigee (router and message processor) set up in our customer facing/external environment while the services/api's reside in our internal environment and to have communication between apigee and these services we open up the firewall. The incoming client only knows about the external environment url and uses the same to come in. If we reverse the flow, the internal services need to send push notifications to external services via apigee how would edge support it? Does the message flow in the reverse way now? ie from message processor to router and then to external service? If yes how is this accomplished? by merely opening up some ports? have additional configuration about this routing configured on some/all apigee components? If no then how will the internal service present in a different network zone communicate to apigee router? please also note that our intent is to use apigee as both forward and reverse proxies.

Thanks,

Vednath

Let me understand - when you say "the internal services need to send push notifications to external services"... you are implying the internal services are invoking APIs (maybe webhooks?) on external endpoints. Is that right? We're not talking about mobile device push notification technology, like Apple's APNS. Right?

Now, let me answer your questions:

> Does the message flow in the reverse way now? ie from message processor to router and then to external service?

No. Requests still get handled by Router, then MP, then remote service. To handle externally-originated requests, the Apigee router must listen on a network interface (NIC) that is accessible from the internet. Conversely, to handle internally-originated requests (webhooks?), the Apigee router must listen on a network interface that is accessible from the internal corporate network. Often, this can be the same NIC, but not always.

> how will the internal service present in a different network zone communicate to apigee router?

By "internal service", do you mean the internal client that will make calls through Apigee Edge? (It may be a service, but it is a client with respect to Edge). If so, it is a matter of configuring the firewall, to do the right thing. You will need an internal DNS name, something like api.internal.mycompany.com, and

  • this name must be resolvable, by internal clients
  • the name must resolve to an IP address that is reachable by those internal clients
  • the router must be listening on that IP address

> please also note that our intent is to use apigee as both forward and reverse proxies.

yes, I think I understand.

@Dino thanks for the input. I think you pretty much answered everything I wanted to know about this. Going by your response i had this question come up, if the flow involved sending requests to mobile device push notification technology rather than invoking external api endpoints what impact does it have ? Will the flow stated above be any different ?

Thanks,

Vednath

@Dino after having worked with our backend service developer based on your comments above here is where we have come to stagnation

We have a backend server that is trying to push some notifications to apple/google servers via apigee (connection/request is originating from backend). For the proxy to be set up on apigee we need to have a basepath and a url mapping defined in apigee and some basic security policies need to be in place too ( to avoid anonymous/unwanted calls) finding a freeway to our internal network. For this same reason to send something out to apple/google the backend request would not only include the hostname and portnumber but it would also need a URL path. How do we handle such a scenario given that our backend is doing the following

ApnsService service = APNS.newService()
.withCert( "src/main/resources/Mobile-iOS-APNSCert-test.p12", "luke****" )
.withProductionDestination().withDelegate(new MobileApnsDelegate())
.withReconnectPolicy(ReconnectPolicy.Provided.EVERY_HALF_HOUR)
.withProxy(new Proxy(Proxy.Type.HTTP, new InetSocketAddress("hostname/ip", port)))
.build();

Please note that i cannot mention the path in hostname/ip (for InetSocketAddress()) as doing so prevents resolving of hostname.
Is Apigee the right solution to be used in such a scenario?

If not how can we leverage apigee

Thanks,

Vednath