I am trying to design a simple microservice application. In a large application where application screens are shown to user based on roles.
Is it a good idea to design a separate user database and create user service to authenticate users.
System Details:
Lets say I have 2 microservices designed in .net core 3.1
Product Service and Orders Service.
Authentication of requests will be managed by API gateway-Ocelot service. User service will be generating token and passing it on to front end who will call my gateway- ocelot which will call Product and Orders service.
I am just focusing on user database for this question scope. Below is what i found so far
Force users to use Azure AD. This way you don't have to manage a separate database
Have user table in both Product and Orders database. This way authorization based on roles will be convenient but here you will be violating microservices concept and duplicating user code.
Related
Our current API leverages ASP.Net Identity and Policy Based permissions for Authorization. It uses User Roles as claims for this. These claims are intercepted by a ClaimsTransformer class and the user permissions are read from a database containing the user mappings (cached). This all works fine.
The problem I'm having is with the API's scope expanding to include different "Projects", such that for instance, a User can be a Creator in one project but a Consumer in another. Is there a way to reconcile these requirements with .NET Core's Role/Policy based Authorization? Or is the best approach here to query the Database for these permissions upon each request?
Authorization is hard and a good starting point is to watch this video:
Implementing authorization in web applications and APIs.
Then using the policies and requirements is how I would approach this and this resource is a good reference:
Custom authorisation policies and requirements in ASP.NET Core
The picture below shows how the concept of requirements work in ASP.Net Core where you can define a requirement and then have one or many handlers independently "vote" if the user is approved or not.
I am working on a project that allows a user to create a user to create app keys or secrets so that specific services can be used by external clients. A user can create multiple secrets that they can choose to use across multiple clients.
For this I am planning to create a decoupled auth server that will use identityserver4.
What really holding me back is that I am not sure whether or not I should create an API layer at the auth server. The reason I am considering API at auth server is so that I can create sort of an admin portal client that will give the users a front-end for creating, renewing, and accessing their app keys/secrets. Even the admin portal is going to be a de-coupled angular application.
There are two things that are holding me back at the moment:
I am not sure if it's a good or safe idea to serve this data via
an api layer. From what I understand, identityserver will not be able to provide functionality that allows me to access a list of a user's clients through an endpoint but please correct me if I'm wrong and there's a better way to approach this.
I know we can easily create new clients and persist it into the database with identityserver4 and I am planning to use ClientCredentials grant types for user clients, but is there a link at the database and identity level between a user and a client? Or will I need to create that functionality by myself?
So far I've looked but I have not bee able to find examples that are similar to my situation with identityserver4
Sorry for the noob question, I am just getting into identityserver and web security in general so many of these concepts are still very new to me.
For number 1, I would say yes you can create an API layer to server data. If you check the IdenttiyServer4 AdminUI, Rock Solid has also use the admin API behind the UI. But you must consider encryption, TLS and other security mechanism to keep this safe.
AFIK for number 2, there are no links at identity level between a user and a client. You have to create that by yourselves.
Basically, you need a system that supports Multitenancy. I have achieved that by adding a TenantId field in the AspNetIdentity user table. And also added the tenant Id to claim list.
Please do not hesitate to correct me if i am wrong.
I'm attempting to build an ASP.NET Core API with authentication/authorization handled by IdentityServer4. IdentityServer4 is being backed by both Identity and Entity Framework Core. My goal is a fairly standard and familiar set up, where users can login into a API developer portal where they can add "applications" (clients) and have a client id and client secret generated that they can then use to access the API, similar to how Facebook, Google, etc. handle API access.
My mental block is coming with the way IdentityServer handles Entity Framework integration. Their entities are attached to two different contexts, ConfigurationDbContext and PersistedGrantDbContext. I'm at a loss for a good way to associate one or more Client entities from IdentityServer4.EntityFramework with one or more ApplicationUser entities from my Identity context.
This seems like it would be a fairly common usage scenario, but the documentation is strangely silent on it. I've also been unable to find anything online after various and sundry searches. I'm hoping someone else has needed this same setup and can give me some advice on how to proceed.
There is no association between users and clients. IdentityServer authenticates users regardless of which client they are trying to access.
If you want to implement something like "which user is allowed to use which client" semantics, that is beyond authentication. This is typically implemented in the application itself since this is application specific logic.
https://leastprivilege.com/2017/07/10/authorization-is-hard-slides-and-video-from-ndc-oslo-2017/
So let's take the basic e-commerce microservices.
Identity and access . This microservice will take care of user accounts, roles
and authentication. The authentication method will be the based on the usual
token based flow (user enters username + pass and server returns a unique and
random token via cookie). This service can also be used to get the user profile.
Cart microservice. This microservice can be used to put products in a cart.
Check what products a cart has. Etc ...
Asuming that "Identity and access" microservice will be used for generating the random token as a result of a succesful authentication, and for linking this token to a user, how will this token be used to make the user's identity available to the cart microservice? For example, when a user will add a product to his cart, he will send along the authorization token and the cart microservice will have to identify the user based on that token.
Could a distributed database be an option? A database which has these tokens stored and links to user built, and to which all microservices have access?
Or should all microservices get the user's identity from a special identity and access API which will expose users based on the access token?
A distributed data base definitely conflicts with the following basic principle of micro services:
A micro service owns its data and exposes it via well defined interfaces.
No other micro service may access data owned by another micro service directly.
So one solution in this case would be to have a token micro services or the last solution you have described.
I am still pretty new to ASP.NET Web API. I am currently working on the authentication part of a new application based on Web API, which is developed using some libraries/kinda framework of the company.
There is already some MVC application - they are using forms based authentication and they are not using the IPrincipal to store information about the user, rather a unity based approach, keeping data in a custom IUser object (basically kept on the session).
The Web API application is going to be stateless (no session), just that I am going to add some user related information in the authentication cookie (retrieved per request in the Application_PostAuthenticateRequest).
I am a bit undecided to keep this user related data in a custom implementation of IPrincipal (as I noticed to be a practice) or use the current approach of other applications in the company utilizing an IUser - served by Unity, using a per request lifetime manager.
Which do you consider to be the better approach?
If you're keeping track of Users per session, try using Singleton classes, if you're about to make a log of the users that entered the session, write it down in a textfile like a whitelist.