I am working in a MVC project that contains both regular MVC controllers as well as Web API Controllers. Initially I implemented Forms Authentication with custom user table. But now I am planning to use the new ASP .NET Identity and change from the forms cookie based authentication to claims based authentication and authorization. I already have a database with tables with custom fields. So I need to customize the ASP .NET Identity to work with my tables
Can anyone guide me on how this can be achieved ?
Edit:
In reply to FKutsche, here is the User table that I have. I have kept only the columns that matter.
User Table
UserId
UserName
Password
UserTypeId
User Type Table
UserTypeId
UserType
The column names are self explanatory so I am not describing them. The User Table has foreign key on UserTypeId column to the UserType table.
There's no point in making this kind of migration if you're not going to use the Identity table format.
ASP.NET Identity has an outstanding out-of-the-box list of features that simply cannot exist without the appropriate db support (and that user table is not capable of providing them).
I think you have different options here:
stick with your user table and build a custom oauth provider on it (it's not too difficult, please check this link - I personally built the security layer of many apps following this guide)
migrate to a brand new identity model with ASP.NET identity and link this table as an extended claim to the IClaimsIdentity generated for the logged user (check this SO answer for example).
IMHO, I personally prefer the second option: you have to migrate your user ids and passwords to the new system, but it's better to start with something solid and well tested. This way you will also have access to future improvements, which is probably not true with a completely customized system without a big coding effort.
Hope it helps :)
Related
I am new to MVC, Have created simple application (very basic, only 1 controller) & used Entity Framework as ORM.
There is form for Registration in application, when I fill up that form user is registered & able to login with those credentials.
But there is no table created in my Database, so my question is where this registration information is stored?
I know this need knowledge of May be Membership/forms authentication, but I don't know them also.
I tried to search google for this, but may be I am not able to predict what to search.
EDIT :
Following is tag of DefaultConnection
Data Source=(LocalDb)\v11.0;AttachDbFilename=|DataDirectory|\aspnet-AKShop-20140808100025.mdf
I think that standard DB was created for your membership. Probably at app_data\aspnetdb.mdf.
Before MVC 5, MembershipProvider or SimpleMembershipProvider by default, and data is persisted in (local) SQL server.
In MVC5, ASP.NET Identity 2.0 by default, and the data is persisted through Entity Framework which by default point to MS SQL, though it is easy to switch the persistence to other DB engines.
Identity 2.0 is quite new, and the official release is April this year, so this is why you got mixed info when searching the Internet. Nevertheless, if you have a green field MVC project, it might be better of to use MVC 5 and Identity 2.0.
I am trying to convert my vb.net 2010 web forms application into a C# MVC 4 application. Since my membership is already setup, I would prefer to just continue using the membership provider instead of the simplemembershipprovider.
Hi,
I am using PluralSight to learn MVC, but have not been able to find any reference on how to convert membership code to mvc.
I have a custom table that is linked by UserID to the mememberships User table. This custom table, asp_customUser, stores additional information about the user.
In the account controller, there is a register action, with the view and model. The register process does not handle roles, much less my custom data.
What I would like to know is, how do I add roles and custom user information to the database, when part of the fields in the registration view come from the membership library and the other part go to my custom table.
Thanks
Yes, you can use the old membership. Just copy and paste your membership provider from the old web.config to the new one.
If this is running on a different computer, you may need to set the machine key, however, in order for it to be able to correctly validate the password hashes.
You would then remove the Simple membership initialization attribute from the Account controller, and you would need to remove all the other simple membership code. You would also be giving up the OpenId authentication, because normal membership does not work with WebSecurity, so you would have to remove all that as well.
When we wanted to extend the membership class we inherited the base membership class and used all the fields in it and the tables linked to it and then create an additional database table with a FK linked to the id in the membership table. Any additional parameters where in the new table and extended class and any standard parameters were in the std membership table and standard class.
I would like to start using ASP.NET's membership classes and tables with a new MVC4 project I am building.
Let's say for example I want to keep track of user's birthdays. When creating the account, how do I add in the birthday? Is this something I keep track of with Profiles? I'm a bit confused on the correct way to add new 'columns' of data for users?
To specifically answer your question, here's how Microsoft advises to create extra tables for storing additional user information: Storing Additional User Information
Here is another posting (I would take this approach), its implementing your own profile provider, rather than using default one, so you have full control over what is happening, how it stored etc.: Implementing Profile Provider in ASP.NET MVC
Another great article by Microsoft about the same is Manage Web Users With Custom Profile Providers
It totally depends on utility and use. You can either
use default profile provider (exercising)
use custom profile provider (small scale sites)
use your own tables to store user information (enterprise level).
In the latter case you can link between default membership (assuming you using default membership provider) and your custom profile information by including user.Guid inside your table, which is used by default membership as unique identifier.
Hope this information will help you.
Profiles is the right way although it has its disadvatages. The data in the database is not in a readable way but in special strings, and profile is loaded on every postback.
Look here:
http://msdn.microsoft.com/en-us/library/z1hkazw7(v=vs.100).aspx
I'm just starting a new project on ASP.NET MVC and this will be the first project actually using this technology. As I created my new project with Visual Studio 2010, it created to my sql server a bunch of tables with "aspnet_" prefix. Part of them deal with the built-in user accounts and permission support.
Now, I want to keep some specific information about my users. My question is "Is it a good practice changing the structure of this aspnet_ tables, to meet my needs about user account's information?".
And as i suppose the answer is "No." (Why exactly?), I intend to create my own "Users" table. What is a good approach to connect the records from aspnet_Users table and my own custom Users table.
I want the relationship to be 1:1 and the design in the database to be as transparent as possible in my c# code (I'm using linq to sql if it is important). Also, I don't want to replicate the usernames and passwords from the aspnet_ tables to my table and maintain the data.
I'm considering using a view to join them. Is this a good idea?
Thanks in advance!
EDIT: From the answer, I see that I may not be clear enough, what I want. The question is not IF to use the default asp.net provider, but how to adopt it, to my needs.
I would create custom membership provider and omit those aspnet_x tables completely. I've seen what happens when one joins these tables and custom ones with nhibernate mappings - pure nightmare.
If you are choosing to use the Membership API for your site, then this link has information regarding how to add extra information to a user.
I was faced with the same scenario recently and ended up ditching the membership functionality and rolled my own db solution in tandem with the DotNetOpenAuth library.
Using the membership system in asp.net has its advantages and drawbacks. It's easy to start, because you don't have to worry about validation, user registration, resetting passwords. (Be careful if you plan to modify the table structures, you will have to change them in the views/store procedures generated
However there are drawbacks to using Membership
You will have to maintain 2 separated systems, because the Membership API has restrictions, for example, you cannot perform operations inside a transaction with the membership api. (Unless you use TransactionScope i think, but you don't have other choices).
A valid alternative would be to implement your own security validation routines, and using FormsAuthentication. This way you will have total control over your users tables, and remove dependency to the membership API.
How would you handle membership in an ASP.NET MVC application? Using any external libraries? How would you do OpenID log in? username log in? email log in? any other that is worth looking into? Maybe all of them mixed into the application?
It seems ASP.NET comes with some pre-build user database (I'm totally new to .Net). The NerdDinner example uses it but then it makes the foreign keys use the username. That doesn't sound very good. Do you use this schema of two separate databases or only one? What do you use as the foreign key, any IDs?
I've found ASP.Net MVC Membership, anybody using it? does it work well? can it be expected to be maintained?
Membership Providers are not new to ASP.Net MVC, they were introduced with ASP.Net 2.0.
The Membership Provider model is simply an abstraction layer between your application and whatever source you are authenticating your users against. You can switch providers easily by simply changing your web.config file.
It is easy to write a membership provider, there are many walkthroughs on the web. Typically you would do so if you were using a database that used a different schema than the default examples that come with ASP.Net (which is most of the time). The foreign keys on the username thing in the NerdDinner example is a simplistic example that you would rarely see on any real-world databases.
I would highly recommend using the Membership model. Controls like the Login control are built to make use of it, and it is well-designed and makes it easy to change or combine different login methods for your application. If you want to use OpenID, a quick google search brought up this OpenID Membership Provider.