Issue with oauth plugin in EMG 2.5.4

Not applicable

We are using EMG (v2.5.4) and are facing issue with the product management capabilities from the OAuth plugin. Some background on our setup first...

We use an OAuth provider outside of Apigee, so the `Authorization` headers from our API calls contains JWT token not friendly to the apigee oauth EMG plugin. The provisioning of our oauth products is derived from Apigee client application registration in Apigee dev portal, so Apigee consumer keys and secrets are used and well known to our identity service.

We have a plugin of our own that validates the Authorization token of each request, and extract from it the Apigee consumer key to use with Apigee oauth. We need Apigee oauth to validate the consumer key (passed as `x-api-key` in the plugin chain) for analytics purposes.

Because we are doing a large, multi- organization rollout of Apigee, we expose API products in a company wide, dev portal enabled Apigee organization ("Uber"- organization), while API proxies are defined in each team, dedicated Apigee sub organization. Our products are defined only using apiResources paths to avoid namespace collision with proxies. Products are promoted from sub to uber organization for publishing on the dev portal.

The Apigee oauth plugin in EMG is configured as follows:

  • oauth:
    • allowNoAuthorization: false
    • productOnly: true
    • allowInvalidAuthorization: false
    • allowAPIKeyOnly: true

The EMG bootstrap URL points to the sub organization, so that we can get proxy mapping configuration, but everything related with product validation goes to the uber org (products URL, verify_api_key_url...).

This worked fine so far, especially apiResource control was working well. We were getting 403 codes as expected when calling an URL that did not match any apiResource path of any product granted to a given consumer key, as passed in the x-api-key header. We only had a minor concern: not setting the x-api-key resulted in 500 error code while a 401 was expected (looks like this is an unexpected side effect of setting "allowAPIKeyOnly").

Now we need to run multiple EMG instances for one of our sub- organization, and we need to restrict the list of proxies that is served by each EMG instance, using the "proxies" configuration entry in EMG.

While this configuration parameter works well to restrict proxies served by each instance, it completely breaks the oauth plugin behavior. Especially, as long as a consumer key is associated to at least one product, it lets any request made with it go through, no matter if the path requested match the apiResource path of the product.

We've done some investigation into EMG oauth plugin code, and found the following:

  • oauth calls the verify api key endpoint to obtain the list of products a given x-api-key is allowed to use (works fine)
  • oauth then gets the config.product_to_api_resource (The list is wrong. Since our products are defined without proxies in the uber org, apigee fails to realize that a given EMG with an explicit set of proxies might be serving those products. It does not seem to evaluate each proxy path against the apiResources of each product to see if their is a possible match or not. As a result, the config.product_to_api_resource array does *not* list the product(s) the consumer is entitled to use, so the config.product_to_api_resource[product] - where products comes from the list in previous step - is undefined. The big "if" in checkIfAuthorized evaluates the else, and suprinsingly the request is automagically accepted.

For our business case, we need the 'product_to_api_resource' element in the config object to consider proxy- less products and match proxy base path with apiResources, when running an EMG with an explicit list of proxies.

We probably need as well the big "if" in oauth plugin function "checkIfAuthorized" to default to "matchesProxyRules = false" and not "= true". This is a big issue for us right now, so any help/ timeline would be appreciated.

Last but not least, getting oauth to return a 401 instead of a 500 when allowAPIKeyOnly is true and no x-api-key is passed would be appreciated.

Thanks in advance for your help, sorry for the super-long question...

0 1 146
1 REPLY 1

Not applicable

Following this post, we made further investigations and decided to open several issues against microgateway-plugins and microgateway-config, namely:

I have started to work on code fixes for these and will submit PRs accordingly as soon as I get the greenlight for the "Company Level Agreement" thing with my management.