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
Related
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.
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.
What's the best way to check if a user is authenticated, and pull her identity & roles for authorization decisions, via AWS cognito within a JAX-RS WebService environment?
I am thinking about the following architecture on AWS:
Server Side: Java EE backend REST-ful services, which requiring authenticated access
Client Side: A variety of apps (mobile / webapps / etc) that consume the services via HTTP
Not wanting to reinvent security, I am thinking about how to integrate AWS Cognito with the JavaEE backend. I am used to Keycloak which provides an AuthAdapter via ServletFilter handling all the integration with the OAuth2 Token Endpoint and leaving me as a developer to work with Java Security Mechanisms.
Clients that communicate against a single point of entry via an API Gateway over HTTPS against a RESTful API
API Gateway: API Keys for tracking and analytics, oAuth for API platform authentication
User Micro service provides user authentication and authorization, generates JWT that is signed and encrypted (JWS,JWE)
Other micro services determine permissions based on claims inside JWT
Micro services communicate internally via PUB/SUB using JWT in the message and other info. Each micro service could be scaled out with multiple instances (cluster with a load balancer).
Question: Can I cluster the the API Gateway and have the load balancer in front of it. What do I need to consider with respect to managing authentication? ie: sharing of API Keys across the API Gateway cluster?
Extra notes, I'm planning on terminating SSL at the gateway and the use of bcrypt for passwords in the db.
Any feedback would be great, thank you.
Can I cluster the the API Gateway and have the load balancer in front
of it.
Yes, you can. Most of the good Api Gateway solutions will provide the ability to do clustering. e.g. https://getkong.org/docs/0.9.x/clustering/ or you can use cloud based Api Gateway: Azure API Management or AWS API Gateway
What do I need to consider with respect to managing authentication?
These specifics depends on your selection of API Gateway solution.