i understand that in the micro-service architecture we can make our requests/responses go through the zuul api gateway instead of directly hitting other micro-services, but is this some kind of just a redirection of requests to zuul or zuul actually intercepts the http request over the air.
What i mean is for example,
If a have a micro-service A which communicates to Micro-service B through Zuul. And if i have some encryption/decryption filters written in zuul, then is it that the request goes as plain text from micro-service A to zuul and from zuul to micro-service B it goes as encrypted request? if that is the case then how exactly is zuul helping us with security, because the request is still plain text over the http?
Related
I have setup and application which uses a React front-end and Expres/NodeJS back-end. There is an ALB in the mix as well.
So, here is how the flow goes:
The ALB listens on port 443 and there is an Authentication action attached to the listener. This action uses and Amazon Cognito user pool, scope is openid. Once the authentication is successful the ALB redirects the request to the React app which in it's turn sends http requests back to the ALB which redirects them to the Express app on the server-side. I have setup the communication between FE and BE like this because we use Amazon ECS and I don't have a static DNS or IP except for the ALB.
I am unable to get the x-amzn-oidc-data header when console logging the req.headers. This header is important to me because I'd like to verify and work with the JWT that it contains.
I have read most of the docs on the Internet and they say that the ALB automatically sends this header (and couple of others) to the back-end. However, I only see one x-amzn-trace-id which has nothing to do with the JWT issued by Cognito.
Where do you think is my error? My setup seems pretty standard to me - how could I get that header?
Thanks in advance!
I'm trying to build a microservice architecture. I've learned some benefits of API gateway like: load balancing, invoking multiple microservices and aggregating the results, cache management etc. So I decided to include it in my system.
My question is whether I should implement authorization in gateway layer or separately in each microservice endpoints ? For example authenticating user on gateway and passing user claims in decrypted form to be used in authorization logic to each service call ?
It seems like it make sense and saves processing time to authorize some aggregates before even calling each service. However, authorization logic is really a concern of individual service.
What is your advice ?
each microservices endpoint. implementing the authorization in API gateway will make your system rigid. If at any later stage you have to separate logic for authorization (say, internal user, external user, open api). This will be very difficult to incorporate.
Authorization should happen at each API level.
You can use API Gateway Pattern / API Gateway. Then you can also offload the authentication/authorization responsibility of the microservice. It will be easy for user or developer that is calling the services. API GW support External /Internal GW even. It may support Role base permissions. eg: WSO2 APIM.
You will get below advantages when you have API /MS GW:
An API Gateway is the single point of entry for any microservice call.
It can work as a proxy service to route a request to the concerned microservice.
It can aggregate the results to send back to the consumer.
This solution can create a fine-grained API for each specific type of client.
It can also convert the protocol request and respond.
We're using an Application Gateway at the moment for our application. It serves two purposes: provide an HTTPS endpoint for public access to our app, and using a Path Rule to redirect incoming requests to the appropriate backend pool based on the URL of the request. Working fine so far.
We're looking at using compression for our responses to reduce the payload being delivered back to the client. Is is possible to enable compression at the Application Gateway? So, when it receives a response, it could compress it before returning it back to the caller? We're trying to determine if we implement this in our application itself (sitting in the backend pools) or can we do this in the App Gateway.
If not, would there be any plans for this?
I'm seeing in my AG responses this header without making any special config:
Content-Encoding: gzip
So I think it is compressing. I don't know how long this has been working though.
We are currently working on a nodejs application which hosts API's (includes both get and post HTTP methods). These server API's in nodejs server are individually accessible or allowed to be called. Like /api/login (login api) is allowed to be called directly from clients.
Next, I want to introduce a service broker API which should be entry point to all API calls from client side. So, any client calling a specific API such as /api/login should go through service broker and then service broker should re-direct to requested API based on the specific service details as sent by clients.
Thereby, all clients should only be able to call only one API (i.e. broker service API - /broker/service). So, all requests from clients should first hit service broker API and then service broker should redirect to appropriate API's based on the input parameters passed to service broker from clients. Input parameters could contain the API URL and input data.
Currently, I'm able to connect directly to individual API's from clients. But, now I would like to introduce a new layer namely service broker and that broker service should decide which API the request should be redirected along with input data (sent from clients).
Note: Both broker service API and other functionality specific API's are hosted under same domain. So, there will not be any CORS issue. We are using "express" node module for handling HTTP API requests.
My initial question is whether this requirement can be achieved?
If yes, then can we perform internal redirection of API's in node server?
Can this be achieved with express node module?
Please help me in this regard.
If you really wanted to go this route, you could do something like this:
app.get('*', function(req, res){
the_route_passed = req.originalUrl;
//handle all of the routes here in your api function call.
});
What this will do is for every single route passed from the front-end will go through your function, and then you can grab the route that was passed req.originalUrl will be like /api/users/230 for user 230. Then you'll need to parse the route or however you want to do it and pass it through to your service broker.
This would be the best way to deal with not having to change anything on the front-end if you are already using Routing. The other way which might be better in the long run:
Send JSON on each request and configure it however you want, and then when you receive it you can figure out all the routing from the JSON request on each go. You'd have to rewrite all routes on the front-end to do this though which might be too much work.
I am currently developing an API that will be launched into production in a matter of weeks. I am relatively new to REST, started reading about CORS - and realized that it could impact me.
What conditions will a REST service not be accessible to a client? I have been using sample html/js on the same server, and through Postman - a google chrome addon - to access my API. I have had no issues so far.
When the API goes live, it will be hosted at 'api.myserver.com'. Requests, at the beginning, will come from 'app.myOTHERserver.com'. Will these requests be denied if I do not use a CORS-friendly approach like JSONP or special 'access-control' headers that permit my domain?
What about accessing rest APIs from other non-browser clients? Such as a C# application? Are these requests permitted by default?
Assuming I do need to add 'access-control' headers server-side, to permit the scenario described above when my API goes live, is it better (performance-wise) to let your web server (NGINX in my case) handle the headers, or should I add them through PHP or NodeJS?
This is more about the same-origin policy applied by web browsers than it is about RESTful APIs in general.
If your API is intended to be used by web applications deployed on a different origin host/port than the API, then you have these options:
Respond with appropriate headers that allow for techniques like CORS to work.
Have the web server which serves up your web content (in your example, app.myOTHERserver.com) handle your REST API requests too by proxifying your API requests from the web server through to the API server. For example, you could have your API exposed on your web server under the URL /api, and then it's just a matter of setting up a web proxy configuration that forwards requests under that URL to your API server.
Use JSONP or other techniques.
If your API is going to be used by non-web applications, you have nothing to worry about. This is only a restriction applied by browsers when running JavaScript code to make sure that the user hasn't inadvertently clicked on a phishing link with some hackery in it that tries to send their PayPal password to Pyongyang.
When the API goes live, it will be hosted at 'api.myserver.com'.
Requests, at the beginning, will come from 'app.myOTHERserver.com'.
Will these requests be denied if I do not use a CORS-friendly approach
like JSONP or special 'access-control' headers that permit my domain?
You can specify what clients can access your web service to an extend. Assuming you're using Express: How to allow CORS?