Making sense of API Product configuration

[willwitman]

An Apigee Edge API Product lets you restrict access to proxy resources based on some combination of proxies and resource paths. When you add a Product to a Developer App, you can use the keys generated for that App to enforce this restricted access.

When you create a Product, Edge lets you specify zero or more proxies and zero or more resource paths to define the “restrictions” you wish to achieve.

But wait, what does it mean if you do not specify any proxies? Or, if you don’t specify any resource paths? Or, for that matter, if you omit both? This is a frequent source of confusion for Edge developers!

API Products 101

Here’s a common Product setup. Let’s say you have a proxy called StreetCarts, which lets you find information about local food carts. The basepath of this proxy is /streetcarts.

Now, let’s say you want to allow access only to certain resources that the proxy knows about. You can do this by adding both the proxy and the resources you wish to allow to an API Product. For example, here’s what the Product UI would look like, where the resource paths /reviews, /carts, and /menus are listed and the proxy StreetCarts is specified:

|

|
| - |

Using an API key from a Developer App associated with this Product, the following call will succeed (assuming ABCD is a valid key and the VerifyApiKey proxy is used in the proxy). It succeeds because the basepath of the StreetCarts proxy is /streetcarts and both the proxy and the resource path /carts are in the Product:

GET /streetcarts/carts?apikey=ABCD

But this will fail, because the resource path /users is not in the Product:

GET /streetcarts/users?apikey=ABCD

This also fails, because the basepath of the proxy StreetCarts is not /foodcarts:

GET /foodcarts/carts?apikey=ABCD

The following path fails as well since the basepath by itself is not allowed in the above configuration. If, however, you do want to allow the basepath, one option would be to add “/” to the list of resources in the product, which (by default) allows the basepath and all subpaths to go through.

GET /streetcarts?apikey=ABCD 

To learn more about how to allow or exclude resources based on wildcards, see Configuring the behavior of a Resource Path of ‘/’, ‘/*’, and ‘/**’.

Be careful when omitting proxies and/or resource paths

Now, what happens if you omit proxies and/or resources from the Product? You need to be aware of potential risks with these kinds of setups!

When you specify resource paths but omit proxies

If you include paths in the Product, but do not specify any proxies, then keys associated with the Product will work for ANY proxy; however, requests will only succeed for the given paths. Consider the following configuration:

|

|
| - |

Given this setup, this hypothetical call will succeed:

GET /basepath_A/accounts?apikey=ABCD

And so will this!

GET /basepath_B/accounts?apikey=ABCD

The basepaths don’t matter, because no proxies are specified in the Product. So, any proxy basepath will be a potential match for the given key. However, proxy requests will only succeed if a valid resource path is given. For example, this call will fail because /carts is not specified in the Product.

GET /streetcarts/carts?apikey=ABCD

When you specify proxies but omit resource paths

If you specify one or more proxies, but no resource paths, then your API key will work with ALL RESOURCE PATHS in the specified proxy(s), including just the basepath.

|

|
| - |

The following API call will succeed:

GET /streetcarts/carts?apikey=ABCD

The following call will also succeed because all paths, including the basepath, for the StreetCarts proxy are allowed:

GET /streetcarts?apikey=ABDC 

However, this will fail, because the basepath for the specified proxy (StreetCarts) is /streetcarts, not /foodcarts:

GET /foodcarts/carts?apikey=ABCD

No proxies, no resources: Beware the skeleton key option!

A skeleton key is a key that opens any lock in your house. If you create a product with NO proxies and NO paths, then the key associated with that product can be used with ANY key-protected proxy in your org. In the UI, such a configuration would look like this:

|

|
| - |

This option may be useful for testing, or for very specific use cases. But be sure you understand the effect of creating a Product with no proxies or paths. Skeleton key!

You can read more about creating products in the Edge documentation.

[anonymous]

@wwitman

@dino

@Ricardo

@support

What is the effect of the “revisions” choice when using the “import resource” type of proxy/resourcePath entry?

Also, will selecting the latest revision allow the authority to automatically update when a new revision of an imported resource is created?

[mdunker]

Great article, Will!

[mdunker]

Revisions are just used to provide the resource path dropdown list when you use the “Import Resource” functionality. They are not saved as part of the product. @wwitman - maybe add a section about the Import Resource box?

[willwitman]

Thanks, @Mike Dunker – I’ll update the doc to make sure this is clear.

[anonymous]

@wwitman @Mike Dunker

Who do i specify the resource for below scenario?

Proxy 1 (StreetCarts)- Access to all resource path (/**)

Proxy 2 (foodcarts)- Access to specific resource path (/carts)

[mdunker]

Hi @Maivizhi A – sorry for the very late response. That is a quirk of products – unfortunately the proxy and resource paths are two separate lists. Even though you think you can specify them together using the UI, there is no connection between the two. That means that specifying /** would give that wildcard (full) access to any of the specified proxies.

[mxr576]

If no API proxy is specified but “/**” is used in API resources, is it also generates a skeleton API key?

[anonymous]

Is there any way I can allow access to all paths but restrict access to just one path without creating a separate developer app.

For example: I have few apis registered with a proxy named say ‘testProxy’ :https://example.com/{paths}

1. I have created an apiproduct (say ‘A’) with path ‘/**’ and proxy ‘testProxy’- allow access to all paths and subpaths

2. I have created another apiproduct (say ‘B’) with path ‘/restrictedPath’ and proxy ‘testProxy’ - access to /restrictedPath only

I have created a single developerApp and approve/revoke access to a particular apiProduct when required. So, If I revoke an app’s access to apiProduct ‘B’ - the /restrictedPath is still accessible because the request goes through apiProduct ‘A’ that allows access to all paths and subpaths.

Is there any way I can specify path in apiProduct ‘A’ that excludes just ‘/restrictedPath’ and let all the access go through. Can I specify a regex in path that achieves this? I am using ApigeeX and not Apigee Edge.

[soosmarci]

Hi @mdunker , @willwitman ,
Could u pls answer @aroy2 's question?
Thx!
M

[mdunker]

I don’t think there is a way to do this with just the API product configuration without listing all of the allowed paths (giving product A all paths except /restrictedPath).

If it is truly sensitive content, I’d separate the content in the proxies. The best solution might be to place the restricted content in a new proxy. Alternatively, you might be able to validate the API product in the /restrictedPath flow, but I’m guessing the separate proxy solution is safer.

The docs provide good examples of resource paths. They cannot use regular expressions.

[Jared1234]

This feels like a major elevation of privilege risk. Can someone explain why this isn’t considered a bug and hasn’t been addressed as such? Because of this behavior we have to implement our own pipeline controls and logic to check for this scenario and prevent a deploy if the scenario is identified.