I have below requirements regarding accessing operations for SOAP services on API GW:
- operationA - accessed by (API Key and OAuth) OR (API Key)
- operationB - accessed by (API Key and OAuth)
How can we accomplish that on API GW 10.3?
We tried API scopes, but our research showed, that when trying to call operationA using OAuth and API Key Authorization header is being ignored (access token is not validated on API GW and is passed to IS).
Any help with that will be appreciated.
Hi Robert Slotwinski,
If my understand is right, you have configured an IAM policy with “API Key and Oauth” at API level and you have configured another IAM policy with “API Key” at scope level.
In this scenario, even if your client sends both API Key and oauth access token, only API Key will be authenticated because scope level policy takes precedence over API level policy.
Please let me know if this answers your question.
If my understanding is wrong, please provide more details on your policy configurations.
Unfortunately - yes.
Is there any possibility to accomplish the introduced requirement?
Perhaps some custom identifiers?
Another way would be to expose separate API with limited visibility of selected operations… But it is a little inconvenient.
Hi Robert Slotwinski,
Can you please clarify what your requirement is?
From my understanding, you want your clients to be always authenticated against “API Key” and you want the clients to be additionally authenticated against “Oauth” only if authorization header is sent by the client. Correct me if my undrstanding is wrong.
I suppose such an authentication scenario is not supported by API Gateway IAM (“Identify & Authorize Application”) policy. If you configure more than one policy in IAM policy (eg: API Key and Oauth as you did), you can either configure them with “AND” condition (evaluate both) or with “OR” condition (evaluate if at least one matches)
I suppose there is no way to mention “authenticate only if the relevant header is present” via IAM policy.
You can explore if Mashup of 2 different APIs (catering to your 2 different authentication requirements) can be used to achieve your usecase. API Mashup is supported in 10.3.
Another option is “Custom Extensions” policy which is more powerful and I believe this can be achieved using “Custom Extensions” but this is supported only from version 10.5.