I want to develop an application using microservices architecture. I'm really new at microservices and until now I've only worked with monolithich approach.
What I would like to do is to have a microservice which takes care of user authentication and have Proxy APIS to authorize the requests.
Authorizing the request in the Proxy API is pretty well documented on the IdentityServer4 docs, but, when the proxy api passes the request to the end microservice how do I authorize this request?
I know that if I setup the end microservice correctly, the same token used in the proxy api can be used to authorize the request at the end microservice. But how do I pass it? Do I grab the token from the request in the Proxy API and pass it down to the end microservice just like that? is it a good practice to do this?
Or is it a better option to block the end microservice to receive only requests from my proxy apis and have no authorization logic there?
PD: I would like to use asp.net-core
I know that if I setup the end microservice correctly, the same token
used in the proxy api can be used to authorize the request at the end
microservice. But how do I pass it? Do I grab the token from the
request in the Proxy API and pass it down to the end microservice just
like that? is it a good practice to do this?
Yes, it is very common to pass the JWT (or any) to pass around, proxy --> service --> proxy --> service.
And each layer can augment the token with additional details like UniqueId (for example when a request hits the first for the first time to track the chain of interactions, circuit breakers etc)
If you are application consists of multiple languages (frameworks), this approach really helps as you don't need to reimplement the authentication in each language and let proxy handle it, this especially useful with container architecture, just make sure that you leave proxy as light weight as possible, you can look into ideas based on Lyft's Envoy proxy.
Related
I joined a project, that already has built all the microservices backends, and they have many API endpoints, something like below:
example1.com/api/a
example2.com/api/b
example3.com/api/c
example4.com/api/d
Recently, the manager of the company asked me to aggregate all the endpoints into one, how can we have just one API endpoint?
Something like below:
example.com/api/a or b or c/*
Is this even possible without help of developers? I mean, no code side changes?
Some of the ideas I have are.
Nginx proxy in front
API GW (but not sure which one suite best for this)
If you just want to get one endpoint and not to aggregate and merge data in one service, AWS API Gateway will help you. It will be a single entry point for client applications and you can re-route multiple requests on multiple backend services on gateway without changing any code.
You can do some integration on API Gateway:
https://api-gw.example.com/users -> integration request on service: example1.com/api/a
https://api-gw.example.com/orders -> integration request on service: example2.com/api/b
Additionally, you can have single authorization mechanism for these resources on Gateway, like Cognito, AWS_IAM, or Custom Authorization.
If you need to aggregate some API responses, you can use lambdas or BFF Pattern.
Hello I am applying a microservices architecture, but I ran into a known problem such as authentication to my apis.
Since I have several microservices, I don't want to handle the authentication in each one of them so I implemented an api gateway with Ocelot for net core 3 to handle the requests.
I was looking at the documentation and it shows the following example from
https://learn.microsoft.com/en-us/dotnet/architecture/microservices/multi-container-microservice-net-applications/implement-api-gateways-with-ocelot
In that example I understand that there is a service that generates the token (identity server) but I can't understand the logic. At login I will go to the identity server and it returns the token and I return it to the frontend, then for each request I send the token to the different microservices (A, B, C) through the gateway api, but how is it possible that the microservices know the token since it was generated in another independent service? What configuration should each microservice have so that it knows and detects the token generated from another service?
I have not found many examples for these cases, I was always used to handling authentication in monolithic applications using JWT. I would appreciate any advice or guidance.
I have a Web API which has two endpoints:
/tenant1/xxx
/tenant2/xxx
The Web API serves multiple tenants and it is hosted as a single instance. Now I have to public this Web API to the outside for using, from the third party, they don't need to know which tenant they should call, instead, they call /api/dosomething (another web API), and inside that API, I will look at the parameter and decide which tenant I should reroute. I use Ocelot as API Gateway but searching on the document I can not find the condition routing. Can anyone help me with this?
Ocelot supports DelegatingHandler which play as middleware for out-going request
I am working on one school project, And my task is to make a simple api gateway, which can placed between any of the 3rd party api and the end users, tha gateway can be used for defining usage limits of the api or to do some security analysis, I am totally new to this, I know the basic concept of API gateway, but don't know how do I implement it using JAVA.
Can anyone please give me some starting point where to start implementation of API gateway?
And what are the frameworks I should use and for what purpose?
Thanks,
Nixit Patel
In a nutshell, API gateway exposes public APIs, applies policies (authentication - typically via OAuth, throttling, adherence to the the defined API, caching, etc.) and then (if allowed) optionally applies transformation rules and forwards the call to the backend. Then, when the backend responds, gateway (after optionally applying transformation rules again) forwards the response to the original caller. Plus, there would typically be an API management solution around it providing subscriber portal, user management, analytics, etc.
So basically any web service framework would work as a quick DYI solution.
You can also use plugin model of an open-source load-balancer such as NGINX.
Or take an open-source API Gateway to learn from it - e.g. WSO2 API Manager (the easiest way to see it in action is the hosted version: WSO2 API Cloud)
Is there a clean way to expose a WCF REST service that requires basic authentication, but where we handle the actual validation of the username/password ourselves? It seems that when you tell WCF in config that you want to use basic authentication, it forces you to turn on basic authentication in IIS and IIS can only do basic authentication against window accounts.
The only hack we have found is to lie to WCF and tell it there is no security on the service and then do authentication outside of the WCF stack using a generic IHttpModule (which has a proprietary config file to indicate which URLs have which authentication/authorization requirements).
It seems like there should be a better way. Anyone have one?
The WCF REST Contrib library enables this functionality:
http://github.com/mikeobrien/WcfRestContrib
It also allows you to secure individual operations.
is the username and password set on the client like:
cc.ClientCredentials.UserName.UserName = ReturnUsername();
cc.ClientCredentials.UserName.Password = ReturnPassword();
Or are they embedded in the body of the REST message?
If the former, you can use a custom UserNamePasswordValidator:
http://msdn.microsoft.com/en-us/library/aa702565.aspx
If the latter, you can set the service to no security, and use a custom ServiceAuthorizationManager to validate the contents of the message:
http://msdn.microsoft.com/en-us/library/ms731774.aspx
Hope one or the other helps! I'd try to post sample code & config, but I'm # home and dont have access to code, which is all # work.
See Custom Basic Authentication for RESTful services. Pablo's approach uses the interceptor functionality that is provided via the REST starter kit to solve the problem. If you do not want to depend on the REST starter kit, then you can create your own service host and use the inteceptor functionality provided.
If you host it on IIS, using custom http module is the way to go. You can bring over the principal over to WCF side to do code access security. See HTTP Basic Authentication against Non-Windows Accounts in IIS/ASP.NET (Part 3 - Adding WCF Support). Also see Custom HTTP Basic Authentication for ASP.NET Web Services on .NET 3.5/VS 2008.
If you are not using IIS, you should be able to implement userNameAuthentication. See Finally! Usernames over Transport Authentication in WCF.
Yes absolutely there is a way. You need to configuring a custom userNamePasswordValidationMode value for your service and point it to a class with an overridden method that can inspect and validate the credentials provided. When making a RESTful call, these credentials when using Basic authentication in its proper form should be in the request header. With this custom method you can inspect the credentials and then authenticate the client to your service. No Windows accounts or domain even needed.
The nice thing is you can then take that security context to the next level and provide fine-grained authrization at the method level. You might have instances where a large pool of clients are able to access the service, but not all methods within (i.e. paid clients vs. unpaid). In this case you can also provide authorization at the method level as well if needed.
Below is a step-by-step solution (with too many steps to embed) by me that contains both the needed configuration and security required to have a complete solution. The problem is often Basic authentication is used without securing the Transport with a SSL certificate and this is bad. Make sure to follow all the steps and you will implement Basic authentication without the need of any type of Windows accounts or configuration on your WCF RESTful based service.
RESTful Services: Authenticating Clients Using Basic Authentication