Secure APIs in Public Cloud Server

[kumudgautam-1]

Hi,

We are using Apigee as our Authorization Server (AS) and we have a few Spring Restful services deployed in IBM Bluemix public cloud which acts as our Resource server (RS).

Each of the services has an equivalent proxy service configured in Apigee. For the proxy services, we have configured the VerifyOAuthTokens policy to verify the token passed by the user and return an error if invalid token is passed

The problem is, since our RS is in the public cloud (no plans or need of moving to a dedicated or private cloud) the api endpoints are open and can be invoked by anyone who knows the url.Though the expectation is everyone should call the apis via APIGEE proxies but we cannot force that since we are in public cloud and there are no options of opening ports coming from apigee or something. We would like to take the following approach to secure the api endpoints.

1. Accept the Authorization header for each call
2. Take the token and call a validate token service in Apigee

For 2, We are not able to find an APIGEE api which can validate an access token similar to say google's:

https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=1/fFBGRNJru1FQd44AzqT3Zg

OR Github's:

GET /applications/:client_id/tokens/:access_token

• Is there actually an external APIGEE service to validate a token?
• If not, what would be the best way to make sure that only valid users with valid tokens can access the apis?

[DChiesa]

Good question!

The situation you describe is a general one; it's not applicable only to APIs hosted in IBM Bluemix.

There are several approaches.

• use transport-layer security (TLS) to authenticate both the client (Apigee) and the server (Bluemix).

  This is the most common option used by Apigee Edge customers. With this option, you configure a cert on the API endpoint (in IBM Bluemix) that Apigee Edge can validate, and you also configure Apigee Edge to send a client-side certificate to IBM Bluemix, that Bluemix must authenticate. This may or may not work for you; I don't know Bluemix or how difficult it is to configure Bluemix to validate a client TLS certificate.

• Use IP-whitelisting at the server (Bluemix).

  In this case, you configure the Bluemix server to allow inbound calls only from the known-IPs of the Apigee Edge proxy. How can you learn your known IPs?

  To get ip addresses for the MPs in an environment, create a proxy and use http://api.lo5.at/info as the target. That endpoint will tell you the IP addresses used by inbound calls. There will be 3 distinct IP addresses for each Edge environment. These IP addresses will be relatively stable, but not indefinitely stable. They may change over time, so you'd need to configure a cron job to check the IP addresses, perhaps hourly, and then alert you if they change.

• use an application-level security option.

  This might be a public/private key pair that you configure, or a shared-secret. Either way you will need to introduce code on both the client (Apigee) side and on the server (Bluemix) side to sign payloads and verify signatures. One way to do this is with HttpSignature, another is with Hawk.

  Finally, you could send your payloads as JSON and sign with JWS. In all cases, because you're using application-level verification, you will need to write and maintain code that does the magic.

The option you suggested - configure Bluemix to call back into Apigee Edge to verify a token - feels a little awkward to me. It feels to me that you ought to be able to allow Bluemix to verify/validate the inbound call on its own, without calling out.