I'm writing a Blazor server application.
In this I would like to use my own user database and not that of Asp.Net Core Identity.
Does anyone have an example of this?
Or can I write a CustomUserManager?
I simply want a login with username and password that is validated in my own database.
The ASP.NET Core Identity is an API that supports user interface (UI) login functionality and helps to manage users, passwords, profile data, roles, claims, tokens, email confirmation, and more. And it is using the EF core to access data from database. If you want to use your own database, you could change the connection string to yours.
If you don't want to use Asp.net core Identity, you could create the Account or Role controller by yourself, and add the login page. Then refer the EF core tutorial to connect the database, and then manage users and roles or validate users.
Related
I developed a SPA app(React and .NET Core) that runs only on our corporate intranet(It's hosted locally). Currently, we are authenticating the users against AD using LDAP.
These are my objectives:
Users do not need to register as every employee should be able to access the app.
We prefer to use SSO authentication method
I need to be able to get a list of the users that are in a specific role
I need to create some tables that stores additional information about users. For example, their roles, paths they're allowed to browse, etc. I am not sure how to do this without duplicating the users in ASP.NET Core Identity. I know If I use Identity, I can extend the users and customize them. But I do not want to register users/manage their passwords through Identity. Is there an alternative? Can I eliminate passwords if I used Identity?
I am not familiar with AD or Azure AD as a different team handles our IT needs. But I did a test in Visual Studio, I created a new web project with Authentication Type set to Microsoft Identity Platform. It was amazing that Visual Studio did all the work on my behalf to create an tenant on Azure. When I ran the app it used SSO and I was logged in. Can I use Microsoft Identity Platform with a customized user table? I just need to have a unique identifier for each user to link it with my other tables. I also do not want to manage the users if that's possible.
I have an asp .net core 3.1 web application that uses the MS Identity (for users) and Entity (codefirst) framework to authenticate users stored in database.
All user rights/groups etc. are stored locally and used to allow/deny access to different areas of the application.
So what I think I need is a way to allow users in my web-app to choose to authenticate using AzureAD account, and when the authentication is done, the wep-app will sign-in the local-user somehow linked to the Azure user
Is this how to do this, or can you guide me to how to do this the correct way
To achieve the above requirements, You can use Azure AD authentication & external login in your asp.net application by implementing the code in your appsettings and controller as mentioned here .
As you wanted to implement the application ,
Consider other options before storing users of your Web applications in a local database. Instead of managing users in a local database, it's best practice to store and manage user information outside of the application, such as with Azure Active Directory or Azure Active Directory B2C. Consider Identity Server if the authentication service must run on-premises. Identity Server is a member of the.NET Foundation and is OpenID certified.
To implement from scratch you can refer this blog.
Please refer the below links for the similar discussion & Documentation to get started with :-
MICROSOFT DOCUMENTATION|Secure a hosted ASP.NET Core Blazor WebAssembly app with Identity Server
SO THREAD|Implement both Individual User Accounts and Azure AD Authentication & .NET Core Identity Server 4 Authentication VS Identity Authentication
BLOG| Integrating with External identity Providers
I have a form to be completed by the user in the ASP.NET Core MVC project. All that needs to be done by the user is completing the form and the admin looking at the users' table with admin access decides whether to contact the user.
I know how to implement Identity or cookie/token authentication, but I was wondering how to implement authorization in this case with just one page and without authentication.
I have a question regarding authentication in my web-app using Blazor WebAssembly ASP.NET Core hosted. The database used is Azure SQL.
I want to avoid storing passwords in the database and the users are therefore restricted to having a Microsoft-account (relevant to the project).
As of now, the user logs in with Azure AD as the third-party authentication provider. When redirected back to the web-app, a user is created with a claim which only consists of the Email from Azure. The user is directed to a registration page where the Email-input is set to the current user-claim email. When the user clicks the register button, the information provided is now stored in the database.
The problem is that I now have a user in the db, but the claim is still just the Email. I want to be able to use the AuthorizeView role tag on the different pages, and therefore wondered if its possible to update the claim with a role that the user specified in the registration-page? This data is at this point only stored in the database.
If this is a bad practice, is there any other similar way I could make this work?
To use the AuthorizeView role, roles claims should be return by your Identity provider (Azure AD in your case). Your application should ask those claims by asking the corresponding scope.
According to the doc : Permissions and consent in the Microsoft identity platform endpoint, the profile scope should return roles claims.
The doc Secure an ASP.NET Core Blazor WebAssembly standalone app with Azure Active Directory explains how to request scopes from Azure AD
I have a solution with 3 projects in ASP.NET Core:
MVC --- no DB (calls the API)
Web API --- MySQL 5.7 own DB
IdentityServer4 + ASP.NET Identity --- MySQL 5.7 own DB
I've managed to get authorization and authentication working between all three apps using in memory clients, users, resources following the great documentation found on https://identityserver4.readthedocs.io/.
Currently I'm using the HybridAndClientCredentials flow which works well with existing users as well as registered users. Newly registered users are saved in IdentityServer DB, using ASP.NET Identity tables.
The problems:
One of my client requirements states that the user should have a profile page inside the MVC app to which the user should be redirected after he is authorized & authenticated successfully.
What I'm doing right now is calling the API in the MVC app, OnTickedReceived event, with the initial claims to create the user in the API DB, but I have doubts that this is the correct implementation.
Since the registration is done and persisted at IdentityServer level and some data about the user is stored there, should I make the profile page there too or should I make a call to the API somewhere in the registration flow to create the user in the API DB too, then redirect the user to the MVC app to input the rest of the details required for a complete profile?
Another requirement states that a user should be able to grant read/write access to another user's details (as in linked accounts or something).
Unfortunately, "it depends".
Let's start by asking "what is the profile page?". What information is on the profile page and is that information specific to your application (MVC/WebApi) or the identity management system.
IdentityServer supports the OIDC UserInfo Endpoint and Profile scope with ASP.NET Identity so that could work well. (http://openid.net/specs/openid-connect-core-1_0.html#UserInfo). You can insert IdentityClaims into the AspNetUserClaims table and get those back when you call the UserInfo endpoint.
But maybe this profile page mentioned in the requirements is information belonging to just the application's domain and therefore has no business being in the identity management system. Then, your current approach is ok- though maybe you could use a Filter Attribute instead of an authentication event (that's just a thought, might not be better).
To me, the decision is about who owns this so-called "profile" information. Is it the identity management system or your business application.
If the profile information can be shared across any client of the identity management system, then put it in the identity management system.