API Key validation error

[anannra]

Have been configuring and testing our proxy for some time now.
I can prove that spike arrest and other features work correctly, but the moment we enable api verification and supply valid api keys, we continually see the following response from the proxy:

{

    "fault": {

        "faultstring": "Invalid ApiKey for given resource",

        "detail": {

            "errorcode": "oauth.v2.InvalidApiKeyForGivenResource"

        }

    }

}

Our configuration is not very complex, as we have just a simple endpoint that takes in a very simple request. 

Users, apps, and keys are all approved from what we can tell, and with api key validation turned off, our proxy works as expected.

any suggestions would be great.

[dknezic]

Can you explain more about the error? Is this a constant error or intermittent?

Is your API Product associated to an environment/s, and are you using a proxy deployed in a matching environment?

Does your API Product have correct operations matched against it? Please refer to https://cloud.google.com/apigee/docs/api-platform/publish/create-api-products#behavior-resource-path

[anannra]

it's all the time.

We have just one environment that we are testing in for the moment.

We can test the proxy all day long with no issue provided API Key verification is turned off, ie, we can load and stress test the proxy all day... in doing so, we're able to confirm our spike arrest limits are being enforced, etc. However, once we enable API Key verification by either including it in the preflow, or setting enabled=true in the xml config, we get the error described above. 

We've confirmed that all apps, API keys, users, etc are all approved.
I suspect it's something really simple that we are overlooking. I'd love to jump on a quick call with someone to have a look.

[dchiesa1]

Running a trace/debugsession can help you diagnose things. Probably there is an assumption you are making, that isn't valid. What I would check

• Your VerifyAPIKey policy - it references a variable I suppose. What variable? how are you passing the API key? If you are passing it as a queryparam the variable in the policy configuration should be something like request.queryparam.QPARAMNAME . If you are passing it in a header, it should be request.header.HEADERNAME . The Debug session should show a GET of that variable. If you do not see the value you expect, then the policy is not seeing the API key you expect.
• Your app credential must be authorized for at least one product . Is it?
• The product must include as an "Operation" a combination of 3 things {API Proxy, verb, path} , that corresponds to the request you are sending in. If any of those things do not match the request, you will see the error you reported. BTW, the path in the API Product operation must be the pathsuffix for the proxy. Don't include the basepath.

If you were passing an APIkey that was not approved, you'd get a different error.

{
  "fault": {
    "faultstring": "ApiKey not approved",
    "detail": {
      "errorcode": "oauth.v2.ApiKeyNotApproved"
    }
  }
}

 if you had a product that was not approved ON the APIKey, then you would see: 

{
  "fault": {
    "faultstring": "Invalid ApiKey for given resource",
    "detail": {
      "errorcode": "oauth.v2.InvalidApiKeyForGivenResource"
    }
  }
}

You would see the same error if the request was being handled by an API Proxy that is not part of the list of API Operations on the API Product. 

I will publish a screencast on this , shortly. 

[anannra]

a screencast would be great.

this is the current apikey-verification xml file :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<VerifyAPIKey async="false" continueOnError="false" enabled="false" name="verify-api-key">
  <DisplayName>Verify API Key</DisplayName>
  <APIKey ref="request.header.x-apikey"/>
</VerifyAPIKey>

 We are sending the api keys in the header with x-apikey as the key reference.  I've asked folks on our team to create accounts, app's, and keys, for which I have tried them all, and still no luck. I suspect there is something we are missing elsewhere that is blocking. As far as we can tell, we have approved everything that is "approvable". 

---

[anannra]

I've reverted the request header back to a queryparam with the correct variable name that the proxy is expecting to see (i think) :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<VerifyAPIKey continueOnError="false" enabled="true" name="VA-tgapi">
  <DisplayName>VA-tgapi</DisplayName>
  <Properties/>
  <APIKey ref="request.queryparam.apikey"/>
</VerifyAPIKey>

Using postman, I can push a query to the proxy, and using the debug session, I can see the request coming with the correct apikey that is approved on all products, but the query is still rejected and the proxy response still indicates "Invalid ApiKey for given resource"

[dchiesa1 · Accepted solution]

ok thanks for that. Either the header or the queryparam should work. 

I understand, and see from the trace, that the VerifyAPIKey policy is retrieving the APIKey you passed in, as a queryparam.  It is trying to validate the thing you passed in.  Therefore we know the problem is not in the configuration of the policy or the format of the request - those are both good. 

you can check the app, key and product: 

• does the app and key exist in Apigee? I know you have an API key. But can you also check the origin of the API Key?   What I mean: The app entity in Apigee can host one or more credentials. The cred is the combination of API key and secret.  (Because you are using VerifyAPIKey you need only the APIKey, can ignore the secret.)   Have you verified that the value you are inserting into x-apikey header (or the queryparam) is actually one of the Keys that is attached to your desired app?  You have correctly copied the value out of the key - there is no corruption or modification of the key value?  No extra characters. 
• The app should be authorized for one or more API products. Let's keep it simple and make it just one API product. Click through the link to the API Product and check the operations on the product. Because you are sending in a POST to /query, your operation should include 
  • the API proxy that is handling the request.  In your case, this will be the proxy that has /tgapi as the basepath, from the screenshot, it l ooks like it is called "tgapi". 
  • at least the /query path.  You can use wildcards like /* or /** to denote any single segment, or any combination of segments, respectively. Any path like {/query , /* , /** } is fine. 
  • at least the POST method (verb).  You can have other methods. 
• If your product does not include the right operation, the VerifyAPIKey will return with InvalidApiKeyforGivenResource. For example if the verb list includes only GET but not POST, ... or if the path is only / , ... Or if you have the "wrong" proxy here, ... in any of these cases you will see the error you are seeing at runtime.  To fix this, Edit the product, add an operation that includes the right combination of {proxy, path, method} and save the product.  Or modify the existing operation to correct the set of methods or the path, or the proxy.

Even after you correct the API Product definition, you may still see the error you observed!!  for a little while.  Apigee caches the API product definition and it make take up to 3 minutes for the changes you have made in the administrative UI, to take effect in the gateways.  

[anannra]

I actually found one of your videos on youtube about an hour ago.... I actually discovered the solution you described about in that video 😉 

[sohamchatterjee]

Which video are you referring to? I am having exactly the same issue with identical configuration

1 API Product and 1Proxy - the verbs are included as ALL in product and hostname is correct

[dchiesa1]

Maybe this one.

[sohamchatterjee]

Yes problem solved - was an error with the path defined in the API Product 

[Sai_teja_1815]

I have the same issue. I have tried everything and even followed the video, but I still get the same issue. can you help me?

[dchiesa1]

hey there

I'm sorry you're having problems. This thread is old and getting kinda crufty.  

I would like you to post your question as a new question. The button to do that is in the upper right corner.