I don't have much experience with api gateways. I've looked into (and setup) Kong with some auth mechanisms. For all of these the user details are added to Kong through their admin API.
How do I setup a complex authentication flow with Kong. i.e: A user registers, some custom business code is run to validate the user then an email is sent to them for confirmation.
The only way I see is having a microservice which talks to the admin api. The UI would then simply talk to this microservice (which would in turn add users to the admin api), am I on the right path?
Using Kong Admin API you could create API consumers which then you can add authentication methods to (JWT, auth0 ...).
The way I have always implemented this was through my backend talking to the kong admin. of course, this means all your backend application then have access to the kong admin fully but that can be prevented by either having a proxy service on top of kong admin which only allows consumer creation and auth management (technically this can be your user service) or add kong admin to kong as a service and restrict the use cases (less secure since any mistakes might expose your admin API).
One thing you should definitely avoid is to access kong admin directly from your frontend app.
Related
I'm analyzing the feasibility of using KeyCloak in a microservices architecture, where there are asynchronous tasks that perform actions on APIs of other services.
The authentication flow that starts with a user action, whether in a mobile or web application, using Keycloak was clear, but I didn't understand how a system can authenticate itself with another system. Does KeyCloak support this type of scenario?
For example:
Every day at 12pm it is necessary to analyze the quantity of a product and make requests to the supplier's API. How will the worker authenticate with the products API using KeyCloak?
You use the client credentials flow to authenticate between services, ie for machine-to-machine communication.
One stragegy is to use the authorization code flow with the users and then client credentials between services on the backend, like this:
You can read more about it with Keycloak here
I'm using KONG API Gateway, and I want to implement JWT authentication as separate microservice (not using KONG plugin), now I can easily register this service with KONG, and so users can register and login. Assume an authenticated user had sent a request with a token attached in the header, how to make KONG forwards the request to the authentication service first, then if it is valid the request is forwarded to the requested service?
Yes you can (But I have not used them) there is as far as I know two options:
https://docs.konghq.com/hub/kong-inc/openid-connect/ Enterprise
https://github.com/aunkenlabs/kong-external-auth Free
I plan to use Kong in our project. I'm currently working on a POC to see how we can integrate it in our platform as the main API gateway. I also want to use the JWT plugin for authentication and authorisation. I know that all the API calls should go through the Kong gateway to be authenticated. Then, if the authentication is validated they can go to the API.
Clients ---> Kong gateway ----> Apis
The part that is not very clear in my mind is how the APIs and Kong fit together.
Imagine a scenario where a client try to call directly an API with a token (bypassing the Gateway). How can the API use Kong to validate this token ?
How does Kong authenticates the APIs (not the Client) ? In the examples I have seen so far, only the authentication of the clients is documented, not the authentication of the APIs that are "protected" by Kong.
When using kong as an API Gateway (or for that matter any gateway) we tend to put it at the point where external clients talk to your service. It is a means to discover the individual services. And kong can do good enough job to validate such request.
For the calls you make to other services from within your set of microservices, you may allow for the free passage by means of directly invoking the service. Challenge in that case will be how the services will discover each other. (One way is to rely on DNS entries. We used to do that but later moved to kubernetes and started using their service discovery), and restrict all the incoming traffic to a given service from outside world. So they can only get in via gateway (and thats where we have all the security)
The reason behind the above philosophy is that we trust the services we have created (This may or may not be true for you and if its not then you need to route all your traffic via an api gateway and consider your APIs as just another client and they need to get hold of access token to proceed further or may be have another service discovery for internal traffic)
Or you may write a custom plugin in kong that filters out all the traffic that originates from within your subnet and validates everything else.
Here a newbie in kong. We have several web apps without authentication in different programming languages and environments.
Our idea is to protect each web app (the web user interface) by securing it with a login screen (single singn on). We want to use kong since APIs are going to be developed and should be protected by kong, too.
Ideally we can use our internal ldap server to manage user credentials.
My questions:
Can we use kong to show up login screen for the web apps?
Do we need to modify out web apps for that?
How to make kong talk to ldap for getting user credentials?
For your questions
Can we use kong to show up login screen for the web apps?
There is no need to do that, for kong authorization most of the time you can send the details in header which kong will use to authenticate
Do we need to modify out web apps for that?
If you need to use the user info which Kong will pass in the header, then you need to modify your app to understand that.
How to make kong talk to ldap for getting user credentials?
You need to configure Kong server to connect to LDAP server. Details about that are provided on the Kong LDAP Plugin page
We are currently analyzing the API gateway for our microservices and Kong is one of the possible candidate. We discovered that Kong support several plugins for authentication but the all based on users stored in Kong database itself. We need to delegate this responsibility to our custom auth HTTP service and don't want to add these users in API gateway database.
It's possible to do this with some code around, instead of using the OpenID connect plugin; in effect you need to implement an Authorization Server which talks to Kong via the Admin (8001) port and authorizes the use of an API with externally given User Ids.
In short, it goes as follows (here for the Authorization Code grant):
Instead of asking Kong directly for tokens, hit the Authorization Server with a request to get a token for a specific API (either hard coded or parameterized, depending on what you need), and include the client ID of the application which needs access in the call (you implement the /authorize end point in fact)
The Authorization Server now needs to authenticate with whatever IdP you need, so that you have the authenticated user inside your Authorization Server
Now get the provision code for your API via the Kong Admin API, and hit the /oauth2/authorize end point of your Kong Gateway (port 8443), including the provision key; note that you may need to look up the client secret for the application client id also via the Admin API to make this work
Include client id, client secret, authenticated user id (from your custom IdP) and optinally scope in the POST to /oauth2/authorize; these values will be added to backend calls to your API using the access token the application can now claim using the authorization code
Kong will give you an Authorization Code back, which you pass back to the application via an 302 redirect (you will need to read the OAuth2 spec for this)
The application uses its client and secret, with the authorization code, to get the access token (and refresh token) from Kong's port 8443, URL /oauth2/token.
It sounds more involved than it is in the end. I did this for wicked.haufe.io, which is based on Kong and node.js, and adds an open source developer portal to Kong. There's a lot of code in the following two projects which show what can be done to integrate with any IdP:
https://github.com/apim-haufe-io/wicked.portal-kong-adapter
https://github.com/Haufe-Lexware/wicked.auth-passport
https://github.com/Haufe-Lexware/wicked.auth-saml
We're currently investigating to see whether we can also add a default authorization server to wicked, but right now you'd have to roll/fork your own.
Maybe this helps, Martin
Check out Kong's OpenID Connect plugin getkong.org/plugins/openid-connect-rp - it connects to external identity and auth systems.