I am trying to create an application that has the ability to create user accounts that have a wide range of permissions. I am currently using the built in ASP.NET Core identity system, but I run into some problems that I haven't find any or haven't find any clean solutions and that will get explained later on the post. This had made me thinking of creating my own custom identity mechanism that will fit my needs.
The problems that I am facing are:
I am using MySQL as my db provider and upon creating the db tables I
was thrown the following exception "Specified key was too long: max
key length is 3072 bytes". I managed to fix this issue by
overriding the OnModelCreating method and manually changing the
HasMaxLength value using the following code
modelBuilder.Entity<IdentityUserLogin>().Property(ul => ul.LoginProvider).HasMaxLength(36);
It's not beautiful but it gets the job done.
I want my users to be able to add multiple emails and multiple
phone numbers to their accounts. The built in ASP.NET Core identity
creates an email and a phone number column in the users table. I know
I can prevent it from creating those columns but I really don't
believe that's the right solution. Basically what I need is to have a
table related to the users table that will store the users' emails
and one for the phone numbers following the same pattern.
My application will have the ability to create dynamic fields and
will also have the ability to give its users permissions related to
those fields (ex. CanSee,CanEdit,CanDelete). The built in Role
authorization system doesn't fit my requirements and I have seen a
lot of buzz surrounding the built in Claims authorization system. I
have actually read that the implementation of an authorization system
that is pretty close to what I need is very complicated and very hard
to maintain!
My question is, should I use the built in ASP.Net core identity system to achieve my goals even though I am facing the such problems? Are there any solutions to my problems that I don't know about and would make my life easier while using the ASP.Net core identity system? Should I create my own identity system and if so, how difficult and potentially dangerous such a system will be?
You should use ASP.NET Identity and customize it.
You should treat claims as permissions. Claims are at their base, authorized filters.
Related
My client asked to build an API in ASP NET Core for a business management application. Nonetheless, he made me an unusual requirement for me: He needs each user to have their own database. All databases have the same structure of tables and relationships and all are MySql.
This means that each user will need their own connection string and some way to store that information.
In addition, other users will be added in the future, each with a bank created just for their use.
Anyway, I don't know if this is possible, but if it is, how would I do it?
I created an MVC Core 2.1 application. Now I need to add authentication (and authorization) to it, but I need to use user membership data used by our old applications (tables aspnet_Users, aspnet_Membership etc).
I have already asked similar question before (How can I use existing ASP.NET Membership data in a new .Net Core project?), but did not receive an answer.
MS posted a howto just recently. It doesn't do what you want directly, instead it migrates data to the new tables. I don't think you can use the old tables without some custom code as the data types and names have changed and the hash algorithms for the password field is different too.
https://learn.microsoft.com/en-us/aspnet/core/migration/proper-to-2x/membership-to-core-identity?view=aspnetcore-3.0
I'm trying to save user-specific settings for my web application, but the amount of information out there is overwhelming me and I'm not sure what the standard way to do this is. It's a Google Maps application and the types of settings I am talking about are things like current map center, zoom level, etc so that when a user exits the application and returns it appears the same way as when they left it.
This is an MVC5 app. We are using Entity Framework database-first for storage, and the Identity API for user logins. My Googling shows that this is built on code-first, so I'm not sure what that means for me. I see a lot of information about the User Profiles API and cookies, but there is so much varying info that I'm not sure what is current or if there is some standard way to do this. I could just add tables to my database and stick these settings in there, but is there some more correct way to accomplish this? It seems like they should tie in to the Identity database somehow since it's already there.
I am building a very simple asp.net application that will have a SQL Server 2008 backend.
Some users will be entering data and storing in the database and some users will be viewing data.
The SQL Server 2008 is working with Windows authentication for every user; however, I am unable to get ASP.NET working with Windows authentication yet. Is there a simple way to allow windows authentication with ASP.NET? I found a very convoluted way, but I don't like it.
I will need to audit every action that the users perform.
Should I audit the users at the application level or at the SQL Server level?
Are there already built in methods to do this? If so, how?
On the contrary, I have always found Windows Authentication to be quite easy to set up and relatively painless. Here's some guides:
Setting up
More Setting up
I didn't realize that you could audit what users did at the ASP.NET level. My answer would be to use SQL Server for this one. You'd need to log:
timestamps and user name for every action
do you need to log workstation or location where the actions were performed?
can users go to mul
if multiple locations use this application, consider storing UTC time only
all actions, even deletes, which mean that delete's only get "hidden" from the user, but never erased from the database. Same for edits, the old record should never be changed or taken out of the database.
Your best bet here is to talk to your boss about this one. Auditors can have very specific needs, and you definitely don't want to forget anything. Every situation is different, so be sure to sit down and double check all your requirements and specifications.
Two things:
Here is example on Win auth on asp.net app:
http://weblogs.asp.net/scottgu/archive/2006/07/12/Recipe_3A00_-Enabling-Windows-Authentication-within-an-Intranet-ASP.NET-Web-application.aspx
I suggest you implement a log framework like log4net to log your application. It's simple and easy to use http://logging.apache.org/log4net/download.html
I would do this from the application if it is significant HOW people accessed the data as much as the WHO, but that's quite different from rlb.usa's answer. In my past jobs, it's often been as important to know which application the person changed data from as when/who. If it's primarily for application issues, log4net is a good option.
I've got a few top-level questions about ASP.NET Membership and Role providers. I've done some searching but am having a hard time finding some layman tutorials. I have been coding in ASP.NET for a while now but the only real experience I have with authentication is the use of FormsAuthentication.SetAuthCookie(usernameFromDatabase, false);
When I use the SetAuthCookie() method above am I using the ASP.NET Membership Provider? Correct me if I'm wrong please but I don't think I am. I am just setting an authentication cookie right? I usually implement my own custom methods in my data repositories like GetUser_ByUsername(string username) which then talks to the ORM and gets the right user.
Do the Membership and Role Providers have their own data storage?
What if I want to use my own data storage?
Do I need to implement my own membership/role provider, and how would one go about doing that?
Or is my way of just setting the auth cookie and then using my own retrieval methods, etc, the best way of doing a custom membership/role provider?
I'm just looking for a brief tutorial/explanation of this system. If you have any good references for me to look at I will happily take a look :)
Implementing a membership provider is not too hard. Note that you only need to implement the methods that you plan to actually use. The membership provider should be viewed as a means to interact with your user information from an authentication perspective. It won't create the auth cookie for you; you do that after a successful call to the ValidateUser method on the provider. It will allow you to develop an application against the provider interface and easily change which provider you want to use via configuration rather than rewriting the application code. I've successfully implemented several different membership providers, using my own schema, which support built-in and hybrid built-in/active directory authentication. More info available via the links below:
Article: http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx
Sample Implementation Description: http://msdn.microsoft.com/en-us/library/44w5aswa.aspx
Sample Code: http://msdn.microsoft.com/en-us/library/6tc47t75.aspx
SetAuthCookie() works with the Forms Authentication framework within ASP.NET which you can then adapt for integration with a membership provider.
Do the Membership and Role Providers have their own data storage?
They can, yes. There is an abstract implementation that you can subclass for your specific data needs. There is a SqlMembershipProvider you can use right out of the box, you just need a database to point to and create the needed tables. There is quite a bit of information on that class, like here or here.
What if I want to use my own data storage?
The SqlMembershipProvider does, but check out this alternative MySQL framework if you're interested in seeing how another DBMS does it.
Do I need to implement my own membership/role provider, and how would one go about doing that?
Using the built-in ones is pretty easy, but a lot of shops roll their own so that they can use existing tables. You'll need to implement this class.
Or is my way of just setting the auth cookie and then using my own retrieval methods, etc, the best way of doing a custom membership/role provider?
In all likelihood you'll need a stronger system, and a custom membership provider is a good idea.
1 - Yes, if you use the built in membership/role providers they use tables created either in a separate database or an existing one. You use the tool aspnet_regsql.exe to create these tables - it walks you through a wizard. Alternatively, it can also be called from the command-line with different arguments in order to skip the wizard. This is some info from MS about creating the necessary DB/tables within your DB.
2 - You can do that, but you have to implement a custom membership provider, which isn't really difficult. Here and here are some tutorials.
3 - You don't necessarily need to unless you either want to use your own data stores or you need functionality from it that isn't present in the built-in providers.
4 - I would say you're better off using the built-in functionality ASP.NET provides for membership and roles.