I'm wondering what to do with an API Endpoint when using a API Gateway. For example when you following the tutorial here: https://wiredcraft.com/blog/securing-components-in-a-microservice-context
You are using keycloak and kong (api-gateway) to secure the api. With kong you're getting an new Endpoint under http://localhost:8000/data. But the "original" express Server is still listening on http://localhost:3001/data.
That means that when a user/attacker knows the url of the "orignal" service and doesn't use the kong url (port 8000) he/she can still work with the api.
So my question is about the strategy and what to do with the original api? How could that be secured. Shall we implement the keycloak request on the api as well? But where are the benefits of kong then?
Your API gateway gives you a single entrypoint that simplifies how client applications access your services. You could add keycloak security on the gateway and not on the services behind - perhaps if you've a setup where you can block network access for clients to any services except the gateway. But even then you might still want the gateway and keycloak on the services behind.
The reason you might put keycloak on the services behind is because they are likely to need to know the identity of the user making the request. If they are going to read the token anyway then it might be most straightforward to add keycloak to them. And you'd still want the gateway to simplify life for clients. You'd then also want the gateway to forward the token to the services behind the gateway. (We're using keycloak and spring cloud gateway on the Activiti Cloud project and this is essentially how we decided to secure the services themselves with keycloak and have the gateway forward the token to them.)
Related
Here is the authorization service. It has endpoints to login and receive a JWT using either a custom username/password or social OAuth (Facebook, GitHub etc.).
I have a Eureka server setup and Zuul gateway service. From what I understand, there are two ways to go about implementing secure microservices. You either proxy requests through the auth service, or you send requests to the requested service (Ex. Service A) and service A authorizes using the auth service.
I would like to use the second way, however I'm having trouble implementing it. Is my understanding correct? Is there a way to setup service A somehow so that certain paths (configured using Ant matchers) will have to authorize using the auth service, which will set the SecurityContext appropriately and inject a UserPrincipal into the request. If anyone can point me to a good guide for this that would be much appreciated.
I have a bunch of rest services. I want to have a kong api gateway implemented at the front. I dont want to go into kong admin api and manually add all the exposed api.
Can i take help of any service discovery implementation like eureka or consul to autoconfigure my apis to Kong.
I'm afraid not.
Kong's configurations are stored in postgres and updated through the admin API, you can write your own program to import.
I'm setting up an environment with an API Gateway (KONG) and microservices (Spring-boot apps), but I have a lot of doubts/concerns with the SSL communication between them.
Should I put the SSL settings in the API Gateway or on the microservices?
Currently my microservice app has its own SSL certificate and it runs in a container through 8443 port.
But now implementing the API Gateway, I'm not sure if I have to remove it from my microservice and setting up in the API Gateway or add it in both.
I expect the correct communication between my microservice and the API Gateway in order to the clients are able to consume the services through 8443/ssl.
Your API gateway will be facing the clients. So for secure communication, your API gateway must be behind the SSL.
Regarding microservice, it's up to you to have it behind SSL or not. Both way it will work. According to me, if your microservices are restricted within the VPC (and API gateway is part of the same VPC) and not exposed publicly, then there is no need to have microservices as well behind SSL.
I'm currently working on a project that uses Zuul to proxy requests to both API endpoints as well as client resources. There is an angular app that is being served from the same endpoint as the Zuul proxy as outlined in this guide. I have the need for additional clients, specifically a desktop application.
I'm not sure I understand how Zuul proxy handles requests and I think there are several paths to get to where I want to go, I'm just not sure what the correct one is.
Here is what I have surmised thus far:
Option 1: Extract the Zuul proxy and SSO capabilities to it's own server. Then create a new UI server which is behind the gateway server. Follow this up with creating a new client application server which handles the authentication of the desktop client.
Option 2: Extract the Zuul proxy and SSO capabilities to it's own server. Serve the current angular app from its own server NOT behind the proxy and change the authorization flow to something different (implicit). Alter Zuul proxy and SSO configuration to ignore requests that already have a bearer token in the header.
If I go with option 2 then I don't understand how to register with the Zuul gateway client that I already am providing the authorization header with my requests so all it should be doing then is proxying my requests to the correct microservices.
Final Questions:
Which option is the most optimal one?
If an access token is already acquired (directly from the auth server using implicit flow) then how does Zuul need to be configured to not try and acquire the access token using the jsessionid?
Suppose there are 2 backend services:
A product service (to get the product info),
An inventory service (to get the available quantity).
Additionally to that, there is a frontend web application to display product details.
All the examples I see on the internet are about the frontend and the API gateway being the same application and using Zuul just as a reverse proxy.
My understanding is API gateway should be a separate application (layer) and frontend application should use it to call backend services.
In that case what is the benefits of Zuul? why not just use feign to create a client for both services and provide an endpoint for the frontend application ?
Feign client and Zuul are two entirely different components in Spring Cloud Netflix.
Feign Client is a glorified REST Template with additions such as Retry, Fallbacks etc. You can think along the lines of Apache HttpClient
Zuul on the other hand is a proxy / reverse - proxy / gateway. Typically Gateway should be a common entry point to your backend services. It should be a separate layer which allows you to add common functionalities like Authentication, Auditing, Logging etc. As #ootero mentioned, you can easily add Filters in Zuul to achieve this functionality.
Zuul as a Proxy server not only route requests but Zuul filters could also be used for handling crosscutting concerns like:
geolocation
token decryption
authentication
request / response manipulation
Traffic shaping
You mention Feign clients and that would work (to the best of my knowledge) with Java-based front-end apps, what if the front-end app is developed with Angular or React?