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
Related
I know one of API Gateway offers is to provide a security layer of any backend APIs. But how if the case is the backend has its own authentication already (let say api key, jwt or other)? What is the better approach / best practice:
Modify those backend APIs to become "plain API" (without any auth), so will rely only on API Gateway auth (OAuth2)
Keep the backend auth as it is, but then create a microservice that will act as wrapper API to handle that backend auth.
The goal is to prevent double authentication & give the same experience to the clients where they only need to pass 1 authentication which is by the API Gateway. Thank you!
I would keep the backend's API security. There is nothing wrong with having secured communication behind an API gateway. As a matter of fact, I recall this being a recommended approach.
To prevent double authentication, would it be a suggestion to define a public (unsecured) end-point on the API gateway to access the authentication end-point of the authentication server used by your backend services. The client receives the authentication token from that authentication server and the API gateway passes the token through to the API of your backend services.
Another possibility could be to authenticate towards the API gateway but let the API gateway use the same authentication server as your backend services. Some gateways allow you to forward the authentication to an authentication server somewhere outside of the API gateway.
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.
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.
I have project with many micro services each one doing its job. One of them responsible for authentication and authorization. But its not clear how other services should check users permissions. Is there any mechanism to deal with this task?
One of the best approaches is the OAuth delegation protocol with JSON token JWT
Authentication in micro-services architecture
the user send his credentials to the OAuth server
The server Checks the user's information (from LDAP server for example), then gives him an access token
the user send his request with the access token to the API Gateway
the API Gateway extracts out the access_token from the request, then he will talks to the Token Exchange endpoint to validate it and then issues a JWT
this JWT That contains all the necessarily information about the user will be sent to the micro-service.
the micro-service also should verify the validity of the token by talking to the token exchange endpoint.
when the token is checked, the micro-service can start its job.
I think this link will be useful for you Securing Microservices
You said that this responsibility belongs to a microservice. So, the other microservices don't check permissions, they delegate.
If you use an API Gateway and the other microservices are not accessible from the outside then it calls the authentication/authorisation microservice before forwarding the request to the upstream microservice.
If you don't use an API Gateway then each microservice call the authentication/authorisation microservice before actually performing the action.
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.