how to apply quota in app level

[rohanjangid]

hi folks,

I have there apps named bronze, gold, and silver and I want to apply quota in these apps like saying as the bronze app can be able to hit API only 5 times after 5 times it will not able to get a response and same for the gold app are able to hit API only 10 times after 10 times it will not able to get response and so on.

i want to perform this thing using custom attribute in app-level like create a custom attribute variable for bronze which store value 5 and somehow it will refer to quota policy 

counter = 5

thanks for any suggestion or guidance.

@Denis_KALITVI please have a look

[dchiesa1]

Normally you would create API Products to store the quota, then authorize the different apps on the respective products.  Like this:

Product name	Quota
Gold	100 requests per hour
Silver	10 requests per hour
Bronze	5 requests per hour

And then you create apps (or allow your developers to request apps) for those products.

Developer	Developer App	...authorized for Product
Chris	devapp1	Bronze
Farhan	fh-app	Gold
Angelique	ang-app1	Silver
Sonia	sonia1	Silver
Cybil	mydevapp	Bronze
Lephron	le-app	Gold

In the proxy, you need to call VerifyAPIKey or VerifyAccessToken. This will explicitly validate the credential for the client app, and implicitly load in the quota setting for the authorized API Product for the app. 

You can then refer to the quota settings as: 

Policy	Variables
VerifyAPIKey	verifyapikey.POLICYNAME.apiproduct.developer.quota.limit verifyapikey.POLICYNAME.apiproduct.developer.quota.interval verifyapikey.POLICYNAME.apiproduct.developer.quota.timeunit
VerifyAccessToken	apiproduct.developer.quota.limit apiproduct.developer.quota.interval apiproduct.developer.quota.timeunit

The required quota policy might be like this:

<Quota name='Q-1'>
    <!-- use the client_id that is set after OAuthV2/VerifyAccessToken -->
    <Identifier ref='client_id' />
    <Allow countRef='apiproduct.developer.quota.limit'/>
    <Interval ref='apiproduct.developer.quota.interval'/>
    <TimeUnit ref='apiproduct.developer.quota.timeunit'/>
    <Distributed>true</Distributed>
    <Synchronous>false</Synchronous>
    <PreciseAtSecondsLevel>false</PreciseAtSecondsLevel>
</Quota>

You can also set quota limits on an app-by-app basis.  But as the number of apps grows, this approach becomes harder to manage, as compared to using metadata set on the API Product.  We presume there will be 10's or 100's of apps, and ~10 API Products (or in any case, significantly fewer products) .  Therefore managing the metadata in the product will be easier. 

But IF YOU WISH to set quota on an individual app basis, you can do that too.  Set the custom attribute on the Apps, and then  refer to different  variables in the Quota policy. 

[rohanjangid]

@dchiesa1 thanks dino for quick and pretty clear reply but my use case is different I want to apply quota at app level using custom attribute value as a counter (In quota) then hit API till quota exceeded

like in custom attributes  counter = 10

then it will go to API proxy and be able to hit proxy only 10 times

[Denis_KALITVI]

It's the same as Dino described. Once you will have your custom attr on app level, you can get it after either Verify API key or OAUTH2 token validation. Once this is done, you will have access to app (via app id) custom attributes, and then you can use this attribute as 

<Allow countRef='policy_with_token_custom_attr'/>

[smalle]

@dchiesa1 How can we acheive this if we have a third party Authentication like Pingone ?

[dchiesa1]

Apigee works really well with 3rd party Authn systems. There are two cases we can consider:

1. 3rd party Authn system is  OIDC compliant. This means, the system issues ID tokens and Access tokens in the way prescribed by the OpenID Connect standard.  In this case, these tokens will be signed JWT, and Apigee can validate the3rd-party generated JWT (either access tokens or ID tokens) by relying on the public keys, which are usually published on a publicly-accessible JWKS endpoint.
2. 3rd party Authn system is NOT OIDC compliant.  In this case, the 3rd party issues some other kind of token, maybe it's opaque. But usually the 3rd party also offers a public-accessible token validation endpoint.  In this case Apigee can validate the 3rd-party generated token by connecting to that token validation endpoint. 

I did a little googleling on PingOne, and... honestly I cannot tell if it issues tokens based on OIDC or not. 

But that is merely a detail. Regardless, the flow with a 3rd party Authn system plus Apigee would be something like this: 

1. User + app connects to 3rd party authn system and authenticates, receives a token in exchange (maybe JWT, maybe some other style of token)
2. User+app presents that 3rd-party generated token to Apigee
3. Apigee validates the token (either via standard JWT signature validation, or validation via the token validation endpoint), and based on that validation, issues an Apigee-generated token. This is a token exchange. 
4. User+app presents the Apigee-generated token in a request for service, Apigee does the right thing with Quotas and rate limits as described above. 

This is a really common pattern among companies who use Apigee. almost all of them have some sort of 3rd-party user Authn system. Active Directory, PingOne, Okta, Auth0, ... Google Signin, ... many options. 

[smalle]

Thanks for the quick reply.Pingone do generates OIDc tokens, will try the approach.