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
Related
I'm building a system with 3 projects and I'm struggling with how to implement user management. I have 3 projects, an asp.net core MVC, an asp.net core Web API and an identityserver4. I want to use asp.net core identity for user management because the framework provides a lot, but I don't know where to place it. The system itself is not a big system yet, but I want it to be scalable in the future. I've read that the only thing identityserver is suppose to do is the authentication and authorization and not deal with the user management part(create users, change permission, etc.)
In the system itself, I need to have an admin that has access to the users (through the frontend MVC) and can create new or delete users, etc.
so the question is, Should i implement all the user management functions that asp.net core identity provides in the identityserver4 project or should I build it in the web API and have the two projects access the same database. I don't want the 4th project only for user management, though I know that is the ideal solution.
Currently, the mvc app only connects with the web API with the bearer token that identityserver provided.
Or, should I go in a new direction and use jwt token and asp.net core identity and only have two projects?
I'm very confused about this part, and I want to know what is the best practice.
Only Identity Server project (and any projects that are related to it) should have access to the user database. All user info a client or a API resource needs, it needs to get it from the IS its self. Now, setting up Identity Server properly depends on your needs. If you want a simple one for a few apps to use, go with a single project that can sign in users and register them, and setup your clients and API resources in the config.cs files. This is not a great way to do it though. Generally, you should have a IS project for user sign in and registration, and one more project that manages those users, as well as clients and API resources. You can see a great example of it here, it also uses ASP.NET Identity, and has a STS project(Identity Server), Admin project(User, Client, API manager) and an API project(for all related db access). Hope this helps.
I am implementing an application using microservices approach.
On my application there must be Google sign-in and basic sign-in.
I have 2 services: 1 for membership service and 1 for MVC gateway.
My membership service has db and standard asp.net core identity applied. So all users stored here.
My MVC gateway has login action that needs to challenge Google and get external login. And then get a user from Membership service for this login.
First my idea was to implement custom IUserStore class and call restful Api methods from Membership service. But there I faced the problem with syncing 2 Identities - on both services. Then I removed Identity from MVC Gateway, but now I cannot challenge Google Sign-in.
So what is the best solution for such approach?
I saw in MS example that there was IdentityServerr4 used, but I don't think that this is viable for my situation.
Implemented using IdentityServer4.
I have following scenario. I write asp.net core web api which will be used by mobile and web (asp.net core mvc web app) apps.
I authenticate user using asp.net core identity framework class SignInManager (add account controller and related classes manually) and then generate oauth token which will be used by client applications. By doing so I have 2 identities associated with the user. one is created by after I login using SignInManager.PasswordSignInAsync and second is created by generating oauth JWT token.
Is this correct approach or not?
Thanks
https://blogs.msdn.microsoft.com/webdev/2016/10/27/bearer-token-authentication-in-asp-net-core/
that might shed some light on what direction to go. there is also another blog post about using IdentityServer4 (3rd party) works well.
https://blogs.msdn.microsoft.com/webdev/2017/01/23/asp-net-core-authentication-with-identityserver4/
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.
I'm designing a solution that involves ASP.NET Web API as the service layer plus clients for web, iOS and Android.
Web users should be able to log into the web site and do their stuff. I'm using Forms Authentication for this scenario.
Mobile users should use the REST API and I believe we need a different authentication mechanism here.
Assuming that a given ASP.NET MVC application can support only 1 authentication mode, do I need to create 2 separate applications, one as the web client with Forms Authentication, and one as the API, and host them separately?
Any advice would be appreciated.
You could do basic authentication for the service clients and combine that with your existing forms auth
http://leastprivilege.com/2012/10/23/mixing-mvc-forms-authentication-and-web-api-basic-authentication/