StreetCarts: Authentication and authorization with Apigee Edge and API BaaS

In addition to its core API management capabilities, Apigee Edge includes tools for app developers in API BaaS, which provides a NoSQL data store you can use as a target backend for APIs. If you're combining Edge's API management with API BaaS's data store, you might wonder where to implement authentication and authorization -- both provide support for implementing these.

This article is the first in a series that suggests one way to implement a complementary relationship between the two products. This article describes how to implement the most permissive category of requests -- those available to anonymous users -- where "authentication" requires merely a valid API key. Other articles in this series describe implementing more restrictive kinds of access.

Note: This article is one in a series that uses the StreetCarts sample application to illustrate implementing authentication and authorization where Apigee Edge and Apigee API BaaS are combined in a single application. The series includes Registering and authenticating new users with Edge and API BaaS, Implementing authorization across Edge and API BaaS, and Updating API BaaS permissions at runtime. By @Floyd Jones, @Steve Traut, @wwitman.

Authenticating anonymous requests

Every request, whether or not from a registered user, can be authenticated to make sure it's coming from a registered client app. To do this, client app developers get an API key from Edge, then pass the key with each request to an Edge API proxy. The key gets passed by the client application whether or not the application's user is logging in.

By requiring an API key with requests, you can:

  • Verify that all requests are from registered client apps. This prevents rogue apps from trying to hit the API.
  • Verify that requests from client-facing API proxies to the internal API proxies (via proxy chaining) are authentic.

In the case of StreetCarts, only GET and authentication requests are allowed for anonymous requests. Because it includes an internal (not client-facing) proxy, a request processed by StreetCarts requires a second API key . Other proxies pass this key when making requests of the internal proxy, which in turn sends requests intended for the data store.

The internal API key is stored in a key/value map provisioned when StreetCarts is set up, then retrieved at run time by an Edge policy. The key, which is only accessible to the org administrator and the client-facing API proxies, prevents rogue apps from hitting the data-manager proxy directly.

Here's how it works in StreetCarts:

  1. Client sends an anonymous GET request for a resource, such as GET /foodcarts in the foodcarts proxy , passing an API key it obtained from the app.
  2. When the request is received, the proxy uses a Verify-API-Key policy to check for an API key in a request header. If a valid API key is included, the request continues.
  3. The request proceeds to the target endpoint in the API proxy flow, where a GetDataManagerKey policy retrieves the API key value from a key/value map.
  4. The request proceeds, using the API key to authenticate with the data-manager proxy.
  5. The data-manager proxy forwards the request to the data store.

2752-anonymous-authentication.png

Version history
Last update:
‎05-23-2016 05:57 PM
Updated by: