Hi Maurizio
Thanks for your reply.
Technically it should work.
But we believe we loose some self service functionality here.
For the self service part we created a custom template for developers to deploy portal published APIs.
If I understand you correct, you suggest to deploy an api without authentication.
You could address authentication in a customized template, e.g. only based on a certificate.
But then we have to add a user to the user group for each deployed api (mapping from certificate to user).
The user group may be created automatically, but then we have to adjust the migration tooling for portal published APIs. And adding the user to the group is still a manual action.
In other words: you simply remove the apiKey generated by the dev portal.
But we believe that is not a good idea. We do not want to loose the generated apiKey, because we think we will use in the future more than one apiKey per application/api,
E.g. we can seperate test, QA and production environments by means of different apiKeys.
The second suggestion is to use the same key for the backend application as generated by the developer portal. But as far as we know we can generate new apiKeys, but you cannot manually set of manipulate them.
------------------------------
[JobTitle]
[CompanyName]
[Country]
------------------------------
Original Message:
Sent: 08-23-2021 07:32 AM
From: Maurizio Garzelli
Subject: API keys in Portal published API scenario
Hi Gerlof,
I am sorry for the delay,
I was checking some information and then the weekend was in the way ;)
Indeed, there is an 'issue' here that is that the APIkeys are created by the Portal to access those APIs when an App developer registers for that particular API.
What I can suggest is the following:
1) Let the app developers use the app registration functionality of the Portal but ignore the APIKey that is generated by the portal, via CSS you can hide that part)
2) You then use a modified encass based on template no authentication when creating an API via the portal, where the modified part will simply make sure (compare) that the APIKey header is there and pass the payload to the backend with the header.
Of course this is the most straight forward way, there are ways to make it a little more interesting, for example to see how we can integrate the APIKey from the backend with the Portal but that will need to be studied for this particular usecase.
I hope this helps for now
Maurizio
------------------------------
Maurizio Garzelli
APIIDA
APIIDA Chief Technology Advisor APIM
maurizio.garzelli@apiida.com
https://apiida.com
Original Message:
Sent: 08-18-2021 05:40 AM
From: Gerlof Bril
Subject: API keys in Portal published API scenario
We are searching for best practices and/or documentation about how to deal properly with API Keys in the following scenario:
- We use the developer portal (version 5) to publish APIs to our API Gateway (version 10).
- These APIs are authorized by the apiKeys generated by the Portal application, the API Key is transported in the http header apiKey, the gateway also expects this.
- These Portal published APIs are deployed in the Gateway as simple Security Proxies, so they do not contain any logic to add or replace data, only to remove the used apiKey header.
Now we have the situation that the backend application also expects an API Key in the apiKey header.
The client requester application has to provide the API Key in the http call to the Gateway.
A simple solution is to rename our apiKey header but we can imagine that is not the way forward and we might run into in a similar problem in the future.
Are there any best practices for this scenario?
------------------------------
[JobTitle]
[CompanyName]
[Country]
------------------------------