Why a developer App is able to access an API Product without really subscribing to the API Product ?

Hello,

I have an API Product helloworld.

I have a developer app helloApp.

helloApp is not subscribed to helloworld, but still its able to access the proxies in helloword.

per my understanding without subscribing, if a dev app is trying to access a proxy in an API Product, it should see a security error.

Am I not following something here ?

5177-helloworld-product.png

5178-helloapp.png

5179-trace.png

0 9 4,527
9 REPLIES 9

hi @Viswa, well documented API product configuration - https://community.apigee.com/content/kbentry/38309/making-sense-of-api-product-configuration.html, thanks to @wwitman!

This should help!

Thanks @Kuldeep Bhati

The above article starts with an assumption that ''A Dev app(with valid keys) is associated with the Product''

and talks about omitted proxies and resources with combinations.

But here my case is different, my product has both resources(tried with /, /* and /hello) and a valid proxy. None of the Dev apps are subscribed to it, but still the proxy in the product is accessible with a valid API key.

Kindly let me know If I am not following something.

5182-proxy-resources.png

Hi @Viswa, I tried reproduce the same scenario as you have, one thing I noticed, is they way you setup of your product, open your product and check `Key Approval Type`, it is automatic.

Note, this property controls whether you want to allow app developer to get access to your product(APIs) automatically or request access to you, read further for this property here - http://docs.apigee.com/developer-services/content/creating-api-products, point 10.

I assume in your case, you created a product, and created a developer app, and as the key approval type was automatic (as I see in your screen shot - helloworld-product.png), it required no approval and it worked.

If in case you want to change this, edit product and change `Key Approval Type`, create a new developer app (as existing is already approved) and test.

I hope this helps 🙂

Thanks @Kuldeep Bhati.

Yes, turning ON the key approval to Manual, will force us to approve the Dev App.

One interesting thing I observed, ''Dev App creation wizard force us to have at least one API Product".....but the same is not true when we try to delete the API Product(s) from a Dev App.

This missing constraint causes to work my scenario.

On-boarded a new dev app (helloApp1), as i turned on the manual approval, its waiting for approval....

.

5186-devapp-waiting-for-approval.png

Dev App Approved

5187-devapp-approved.png

Now revoke and remove the API Product from helloApp1...Interestingly it wont force us to have at least one API Product....

5188-revoke-and-remove-apiproduct.png

Now I can access the proxies in the product with the helloApp1's key w/o actually subscribing to it....

Generally speaking, a Dev App with NO products, should not have access to any resources.

: - )

@Viswa that's really interesting, may be best to raise it to apigee support 🙂

@Dino could you kindly share if you have any clue on this ?

Hi @Viswa

What information are you seeking? I don't know exactly the question.

Here's what I think:

  • The Developer app Editor forces you to select an API product on initial creation of a Developer App. In actuality the entity model in Apigee Edge does not require a Developer App (actually a credential) to have at least one API Product. When you use the editor, you can remove all API Products from a credential. This is a valid configuration. It may seem confusing, as this configuration is disallowed on initial creation of the dev app (But please note - this is disallowed in the UI only!! It is not disallowed when you create a devapp with the administrative API. In other words, if you use the admin API, you can create a devapp with a new credential and no API Products associated to it). We do not consider this to be a bug. The reason we have the UI disallow the scenario on initial creation is that we want to encourage the typical correct, desired behavior in the UI. It is unlikely that people want a devapp with no API Products, unlikely but possible.
  • When a devapp credential has no API Products associated to it, that credential is implicitly good for all API Products. I believe this is documented behavior, but I don't have the doc citation handy right now (I'll look).
  • Key approval (manual or automatic) will not affect what I have described above.

In the original post, you wrote

per my understanding without subscribing, if a dev app is trying to access a proxy in an API Product, it should see a security error.

The actual behavior is slightly different than that.

A devapp (credential) that has at least one API Product associated, will be good for only that set of API Products. A devapp credential that has no API Products associated to it, will be good for all API Products.

To avoid the case where a key or token is treated as valid at runtime, be sure to always associate credentials with at least one API Product.

Is it clear?

Thanks @Dino for you inputs.

"When a devapp credential has no API Products associated to it, that credential is implicitly good for all API Products. I believe this is documented behavior, but I don't have the doc citation handy right now (I'll look)." - appreciated if you provide the link.

Hi @Dino

I am facing similar problem where in for X app, I initially added oAuthProduct which contain oAuth generate token proxy & Xproduct which contains set of API proxies. Later, i revoked oAuth product in the app. My expectation is that generate token return error if i use X app credentials since i revoked oAuthProduct.

But oAuth policy is returning token for couple of attempts.

I do have atleast one active API product in X app along with revoked OAuthProduct.

Is there any wait time for the product revoke action to reflect in Message processor or Cassandra ?

If so, what is the best approach to immediately restrict the Apps not to generate the token?

Also, tokens that are generated ( that have 1 hour expiry) are still able to access the APIs even though we remove the API products from the App.