How do I associate ApiProduct from JwtValidator

[momojabba]

We are trying to migrate our existing API to use ApiGee.  The current setup has its own authorization server and we do not want to change that.  So, I have so far created API Proxy to decode access token properly in ApiGee using VertifyJwt policy.  But I cannot seem to find a way to associate the flow to an ApiProduct without using OAuth2 policy.  We need to associate to ApiProduct in order to enforce rate limit based on client-id in the access token.  The client-id is NOT generated by ApiGee but by third party IdP.

I was reading this thread, https://www.googlecloudcommunity.com/gc/Apigee/How-to-validate-Quota-Policy-against-JWT/td-p/29607, and it mentions using VerifyApiKey policy but it seems that ApiKey must be one that was generated by ApiGee.

[dchiesa1 · Accepted solution]

Thanks for the clear explanation of your question!

it mentions using VerifyApiKey policy but it seems that ApiKey must be one that was generated by ApiGee.

Correct.

The way to get API Product authorization enforcement in Apigee is to use VerifyApiKey or OAuthV2/VerifyAccessToken. Include either of those policies in your proxy request flow, and Apigee will check that

• the client id is valid, known, and not expired.
• the Developer app has not been revoked
• the developer has not been marked revoked
• the product is authorized for use by that client ID, and has not been marked revoked
• the specific request (GET /POST/PUT etc on a specific path) is authorized for use within this API Product

(Obviously in the case of VerifyAccessToken, the policy also checks that the token is valid, not expired, and has the right scope)

That's a lot of checking, and it comprises the best and most valuable way for Apigee to perform authorization and app-based (or client-based) access control on APIs. And of course Authorization and access control is the one of the key foundations of "API Management".

Typically if the token is issued by Apigee, then you'd use OAuthV2/VerifyAccessToken. If the token is issued by a third-party, then you can use VerifyJWT first, then VerifyApiKey. But the API key that is embedded in the JWT has been generated by the third-party IDP, and is not known by Apigee. Which means VerifyApiKey will reject it as unknown.

What to do?

There's a simple solution. Import the external API Key into Apigee. Within the Administrative user interface, it is not possible to just "paste in" an API key to import an external key. But, there is an administrative API that allows this. This guide discusses the approach. Here is the reference of the Apigee API that allows it.

[ajay-1]

Assuming you are using the quota policy for rate limiting you need to set the Identifier element to a unique client value (may be some value from the jwt)

https://docs.apigee.com/api-platform/reference/policies/quota-policy#set-identifier

Have the quota policy run after the VerifyJWT policy, and assuming there's a claim in the JWT called client_id , your quota policy like

<Quota name="QuotaPolicy" type="calendar">
  <Identifier ref="jwt.jwt_policy.client_id"/> 
  <Interval>1</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

 The above would allow 99 requests per hour per client_id.

[dchiesa1]

Yes this will work to perform rate limiting.  It won't work to implement product-driven rate limits.  And it won't address the product-level authorization I mentioned previously.  Whether you want all that, is sort of up to you.  (I'd recommend it, though)