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.
Related
I am developing ASP.Net Core App with Backend For Frontend pattern using Ocelot. For now there will be a single API service but in the future I might migrate to microservices. Let's say it will be an e-commerce system where I will create different web apps for customers and for employees. I may also have Mobile app for customers.
From my research I know that should have my main API, then two API Gateways and two client (angular) apps. There also needs to be separate IdentityServer app.
So my question is - is there a way to configure the IdentityServer and gateways in such a way, that when I log in app for employees I won't be authenticated in customer app? I cannot understand if it should be possible with right configuration of scopes, claims or audiences. I saw many examples where that properties were set completely differently. I can prevent user from accesing some endpoints with the use of Roles but I think that it's not the right way to do this.
Or maybe since IdentityServer has built in SSO I should not use it and move to different authentication provider?
You should let the authorization sub-system in ASP.NET Core decide if the user is allowed or not, typically based on the claims in the access token.
You need to understand that you handle authentication and authorization separately in ASP.NET Core as the picture from one of my training classes show:
For more details:
Introduction to authorization in ASP.NET Core
Policy-based authorization in ASP.NET Core
Claims-based authorization in ASP.NET Core
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.
I am new to Identity server and wants to secure my two apps (MVC, Webapi) using it.
I have seen the example where we can invoke the webapi from MVC action method and SetBearerToken that was issued to the the MVC application. I am referring the below sample:
https://identityserver.github.io/Documentation/docsv2/overview/mvcGettingStarted.html
This is typical example of server to server communication where we are using access token issued to the MVC app for Web api.
In the same scenario, I want to call webapi from Javascript client(fro ex Angular or any one) using same access token.
"I want to pass the the access token issued to the MVC application to call WebAPI from JavaScript"
How can I utilize the token that was issued to my MVC application from the JavaScript client?
Thanks
They should be treated as different client in my opinion, I guess they are different site? For your Javascript client you should be able to find example here , you can use the javascript lib that provided in the example or write one yourself
Once you get the token, then you can call your API using AJAX, where you might face CORS problem if your webapi is on a different domain, well...that is different topic.
Hope that helps
I'm working on segregating the authentication part of my ASP.net MVC4 application using DotNetOAuth 2.0, Which will means that one project will do only authentication and send out response,based on response it will have access to other application.
The Idea is to get any application or project added later on use one common authentication process.
First thing came to my mind was building a service, in the process a read a lot about Web API and think it can help to achieve what I'm looking for.
Please suggest if you guys have implemented something like this or whats's the best practice.
Should i go with API or service, any link or sample to direct is appreciated
ASP.NET Web API is also a service - a RESTful service. The choice of using a "Service" although is good your underlying authentication platform will define what you should be using.
WCF is much more than a web service where as a Web API is pure HTTP service.
If you expect all your "applications" to be web based then there is no reason why this cannot be a Web API.
This article might be something that should help you decide on your authentication model: http://www.asp.net/web-api/overview/security/external-authentication-services
I am creating a distributed application which will use ASP.NET Web API to support a Single-Page web Application (SPA) and other potential native mobile app platforms. My current architecture uses Thinktecture Identity Server as a STS which will provide authorization tokens for my clients to use to access the WebAPI. In the backend I will have persistence and business logic which will be exposed by a WCF service in a separate app domain from my WebAPI. The WebAPI will call the service layer to access data and perform actions on the domain.
My question is around authorization. I will be using Claims Based Authorization and can augment the list of claims from domain data held about the user from my WCF exposed business layer. But where should I carry out the authorization? With .NET 4.5, ASP.NET now has an extensible model to enable me to separate out authorization logic from my controllers into a separate authorization module - using the ClaimsAuthorizationManager. Also, Thinktecture.IdentityModel does a really good job of providing all the plumbing to do this within my WebAPI application. However, I cannot help thinking that the authorization logic should be sitting in my business layer, behind the WCF service, and that the client-facing WebAPI should not be tasked with enforcing this. Should I require other client facing hosted apps to consume my WCF based business layer, then they would also need to implement security code. On the downside, it does mean that an unauthorized request gets quite far into the application before being rejected.
Question: should I use the Claims based authorization capabilities in ASP.NET or should I wrap authorization around my business layer behind the WCF service?
When possible, you should always try to use the authorization tools the framework you use gives you. In Microsoft's case, it's claims-based authorization. The benefit is that you're isolating your authorization logic in a layer of its own rather than within your business logic.
Claims-based authorization is one of many approaches to authorization. Another would be to use XACML. I recently gave a talk on XACML for developers (albeit Java developers). You can read more about it here. I also wrote an article on .NET and XACML which you can check out here.