We currently use Kong as an API gateway with all endpoints requiring authentication.
We need to build a public facing web app that retrieves information from a service and we want to use the Kong API gateway and other technologies that are familiar to us.
Some of the options we are considering are:
Use api key authentication having the api key exposed via the internet on the public website (this will at least allow us to rate limit as we are likely to have a multiple consumers of this service)
Use anonymous authentication on the endpoint
Build another web app and use it as a proxy to kong with basic authentication between the two (i.e user -> web app -> kong -> internal api, rather than user -> kong -> internal app)
I wanted some feedback or suggestions on what way we should go.
Related
This is a design question
We have keycloak as Idp and Mule as API gateway, both on-premise DC.
As per design all traffic to DC will go through WAF
All external calls to our apis(microservies), will follow this path ExternalSystem-> WAF -> ApiGateway -> Microservices.
Ideally, should the issue access-token endpoint should follow
4.1 ExternalSystem -> WAF-> http://keycloakxx:/auth/token
or should it be behind api gateway like
4.2 ExternalSystem -> WAF -> API gateway -> http://keycloakxx:/auth/token
Since WAF can already take care of security measures like DDos, what are the advantages/disadvantages of going with option 4.2
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'm experimenting with Kong API gateway. It has nice features such as API key and HMAC authentication via plugin, so I don't have to implement my own security into each of my API.
But it seems to be trade-off. Suppose I have Payment service. In it I need to check for API key, so I create request interceptor for each request to payment service, needs to provide valid API key.
I use kong as reverse proxy to payment server upstream. I also want to move this API key validation into kong, so my payment service (and other service) become plain-not-secured API. It seems nice since I don't have to re-write interceptors for each service. But if somebody know the IP of payment service, then they can directly hit payment service without Kong API gateway.
What should I do to achieve these:
use kong as API gateway (reverse proxy)
use kong plugin for validation (API key / basic / HMAC) so I don't need to re-configure them in my services
avoid security hole if somebody knows the address of API, and hit them directly (bypassing kong security), but keeps #1 and #2, so the API programmers write is simple API but keep secure
Thanks in advance
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 several web services that I want to make available to clients. My clients are split into two groups:
users using a web browser (I serve a web page that uses javascript + AJAX to request data from the web services)
applications (e.g. server app pulling data into a client's system)
1) I can solve the former by exposing my web services to external users using the application server and I can use the identity server to authenticate access (haven't worked how to do this out yet).
2) The latter is nicely satisfied by using the API manager. I can happily tell clients to log in to the API manager and subscribe to APIs. The APIs I create are proxies for the web services mentioned in 1).
I know that an API I create in the API manager can include a username and password for accessing the proxied web service. Is it possible to let an API proxy a web service that is authenticated using the identity manager? Sorry I'm reading documentation and struggling to understand if I can do this. Thanks
". Is it possible to let an API proxy a web service that is
authenticated using the identity manager? "
Currently APIManager supports the service endpoints which are secured using basicauth/usernametoken.
If you use identityserver to secure you service, using any other mechanism, that wont be supported by APIManager.
Stodge,
Default API manager authentication mechanism is Oauth. it uses Oauth token mechanism to authenticate all APIs.
Please refer [1],
Here the authentication component also sits in the AM. This can be delegated to a different AM instance if required.
Hope this helps.
[1] http://docs.wso2.org/wiki/display/AM140/Token+APIs