API Key not in param or header

pxzxz1
Participant IV

Hello fellow Apigeeks

Can I use DeveloperApp and AccessEntity Policy, but I am unfamiliar on this.

Does anyone know about this or anyone who can advise how I can use apikey?

0 4 235
4 REPLIES 4

pxzxz1
Participant IV
@Dino-at-Google

Do you know this? Please advise.

I understand that you are using Apigee to proxy a SOAP call. The SOAP interface is described by a WSDL.

You don't wish to force a change to the client, so that it must pass a different header or query param.

You want to know, how can Apigee authorize calls under these constraints.

This is my understanding.

If that is what you're asking, then... the answer is.... you cannot do that.

In general, Apigee needs a client credential in order to perform an authorization check."Credential" means APIKey or an OAuth token derived from the client_id, or a JWT which is signed by the client's secret key or private key, and so on. In any of those cases, Apigee can verify the credential and then make a decision on whether to authorize the call.

If the client doesn't present any credential, ... in other words...if the client doesn't present any bit of information that allows Apigee to distinguish a request arriving from client1, from a request that arrives from client2, then by definition Apigee cannot make an authorization decision.

The easiest way to send credentials is via a query param, or via an HTTP header. In the SOAP case, this is not always easy, so... Another way to do it would be to send the credential in the SOAP:Header element. This is what the SOAP:Header is intended for, in fact.

Then you would need to use ExtractVariables, extract the credential (can be an apikey or token or JWT or similar) and then authorize based on that extracted value.

You WOULD need to change the WSDL in that case.

There are outlier cases. For example, you could have clients that connect from fixed IP addresses. You could configure your Apigee proxy to infer that any request arriving from a IP 1.2.3.4 would be authorized as client ABC, while a request arriving from IP 203.41.187.12 would be authorized as client DEF. This is not a grand idea, as IP addresses change in the cloud.

Another similar, but better option is to use 2-way TLS, and to use the identity of the client as asserted in the TLS certificate, to authorize the API call. But that means all of your clients need certificates, and maybe that's a bit heavy for your purposes.

One way or the other, you've got to attach a bit of information in the client request that Apigee receives, that would allow Apigee to distinguish requests from different clients.

Lots of options, just choose one.

I guess the fallback is ... there is no way to distinguish a request between different clients. A request from client ABC looks exactly like a request from client DEF and there is no way to distinguish them. In that case Apigee can still proxy the calls, but Apigee cannot make any intelligent, useful per-client authorization checks for you. Maybe that is obvious, but in case it is not, I wanted to point it out.

==

I do not want to change the flow of how I access to the target endpoint, in another word, I do not want to have apikey on the param nor on the header.

==

If that is true why don't you have api key validation and remove authorization header so that it doesn't flow to backend target..

Without any auth what is the point in exposing api?

Client -> ( sends API key /some kind of auth) -> APi gateway( performs key validation & once it is done remove the headers) -> Target

Not applicable

if you don't want to send the api key in the request to target, then use the api key in header or query param to the apigee api and inside the api remove the header or query param using assign message policy, so that same will not go to backend.

If at all you don't want to send in header or query, then send in body, extract that inside proxy using javascript or some policy, set in header using proxy, do apikey verification, remove after verification and also modify the body if required.