so our organization is developing some new web apps using asp.net mvc and web api. we decided to not use active directory for authentication/authorization purposes so it looks like asp.net identity with entity framework might work.
looking at the database schema i don't see an applications table so we can have one central repository for user credentials and application access. is this where claims come in? how would that look; user -> app -> role -> permissions
also, one of our goals is to also provide users with single sign on. is this possible with the new bearer tokens?
thanks for any help you can provide
ASP.NET Core Identity: Is an API that supports user interface (UI) login functionality. Manages users, passwords, profile data, roles, claims, tokens, email confirmation, and more.
ASP.NET Identity uses OWIN middleware for cookie-based authentication. We need to configure the OWIN cookie middleware to store a two-factor authentication cookie in the request. The cookie middleware in the application is configured during application start via the ConfigureAuth method in Startup.Auth.
In ASP.NET Core 2.x apps, reference the Microsoft.AspNetCore.App metapackage. In .NET Framework apps, add a package reference to Microsoft.AspNetCore.DataProtection.Extensions. SetApplicationName sets the common app name. When using ASP.NET Core Identity: Data protection keys and the app name must be shared among apps.
When the Identity schema is different among apps, usually because apps are using different Identity versions, sharing a common database based on the latest version of Identity isn't possible without remapping and adding columns in other app's Identity schemas.
Take a look at this tutorial. It shows how to implement ASP.NET Identity using Web API:
http://bitoftech.net/2015/01/21/asp-net-identity-2-with-asp-net-web-api-2-accounts-management/
As for dealing with multiple applications. Two approaches that come to mind are:
AppId
to all usernames AppId
column to AspNetUsers
table, derive from UserStore
and re-implement the Find
based methods so the queries take into account the AppId
For #1 when the application wants to create a new user it would send a request to the WebApi containing the new user information and an AppId
. The WebApi would then concatenate the UserName
and AppId
to create the complete username that will be written to the database. So, if application 1234
wants to create a user with the username myuser
, then the WebApi will create a new user with the username myuser_1234
. From that point on when querying the database you would first take the UserName
and AppId
from the request, concatenate them and then query the database.
If another application 9900
wants to create a myuser
, then the final username written to the database would be myuser_9900
.
You may want to store the application details in the database and for every request validate the AppId
to ensure that you recognise the application before processing its request.
I've not thought much of step #2, so its just a suggestion.
If you wanted to share the user credentials across multiple applications, then you could probably ignore the above, go with standard functionality and just have all applications point to the same database therefore allowing all applications to access all users regardless of which application created which user.
UPDATE #1: In this instance bearer tokens could be used and I think (going from memory) the tutorial series mentioned above touches on this and how a single WebApi can provide tokens for multiple applications.
Your users and their credentials are stored in AspNetUser
table and Roles are in ASPNetRole
while AspNetUserRole
serves as junction table between the two to map users and roles. You can implement SSO (Single Sign On) by sharing these tables in your applications. Like each application will need to read these tables and roles and login users. But a better approach would be to create a central WebApi to handle user authentication and authorization.
Also if you Roles can be changed at run time then you have idea of Permissions, You can create a custom Table for storing permissions and then map Roles to Permissions. And when user logs-in just load all his permissions and store as claims. You can either serialize whole Role (with its permission list) and Store it as one claim. Or store each permission as individual claim whichever suits you best.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With