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
Related
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 :)
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 have a site which has an area that requires authentication. Right now I use the roles attribute on all the controllers in that area, and I run a query to retrieve that users ID, and all their settings.
It seems like a code or design smell to me that I am retrieving the userid and settings each time a controller in that area loads up? I'm not sure if I should be using sessions, or if ASP.Net MVC 2.0 provides some unique way to handle this. Another concern is security.
Overall, I don't really know which way to turn. Design wise I would like the userId and settings retrieved only once when the user logs into the area. Right now I grab the userId each time a controller loads up, and then if required, I query the database for their settings each time as well.
One of the rules about security is that you shouldn't try to do it yourself. There are many pitfalls in doing an authentication system correctly without leaving loopholes or backdoors. Thus, in that regard, you might consider the SqlMembershipProvider that comes with .NET. It can be used with MVC and provides the means to get roles and the current security context, is easy to setup and configure and will be more secure than rolling your own.
If you are not using SQL Server, you have a couple of choices. One solution would be to use something like SQL Server Express or SQL Server Compact Edition to maintain the credentials. Another solution would be to mimic the SqlMembrershipProvider database schema and then write a custom provider that communicates with that schema.
The last choice would be to write a custom MembershipProvider class. While this is still rolling your own, it forces you into the structure of the MembershipProvider so that you can swap it out at a later date for a different one (e.g. ActiveDirectoryMembershipProvider) and provides a common interface for interacting with credentials and logins which for example enables easy use of the built-in Login control.
If you are already using a MembershipProvider and are asking about storing additional user-specific data, then I would suggest the SqlProfileProvider with all the caveats I mentioned above about the SqlMembershipProvider. the ProfileProvider provides a structure for maintain user-specific data with the currently logged on user.
For more information:
Introduction to Membership
Implementing a MembershipProvider
ASP.NET Profile Providers
You could also implement a custom identity. They are very easy to implement, and they let you store whatever user information you want in Identity, which is then stored in the cookies that Identity puts down, so you're not hitting the DB every time to get that info.
Just create a new class that inherits from GenericIdentity, and you'll be on your way.
You of course have to be careful how much info you put there since it's in a cookie, but usually user related information in the case you're talking about here isn't so big.
We use a custom identity to store a few bits of info about the user, and it works out pretty well.
You could store an object in session that holds all the required user information. You will just need to add a property in the Controllers, Views or other base classes where you want to retrieve the user information/profile. This would be the authorisation info as opposed to any authentication info (eg Forms authentication)
You might try "Windows Identity Foundation". I've been using it on one of my projects for a while. It allows for "claims-based authentication", which basically means that you get to designate "claims", strings of information that describe the user when she logs on.
Once logged on, the user's claims can be read from the HttpContext.Current.User field. You can also use "Role" claims that seamlessly integrate with a role-based authentication schema; meaning that you can give the user a "manager" role claim and then use `if (User.IsInRole("manager")).
As an added bonus, WIF makes it very easy to re-use your login screen in other applications.
All in all, it's very flexible, but the documentation is very poor. I've asked and answered a number of questions about "Windows Identity Foundation" on StackOverflow.
We have done this quite a few times in the past. Similar to what Thomas mentions, what we have generally done is implemented a new Membership provider based on the Microsoft SQL Memberhsip provider to do this. We inherit from the base MembershipUser class and add any custom properties we would want to have on the user object. You have to implement a database read for the Membership provider on the GetUser implementation, so you can consolidate your extra properties you need into that database read.
If you are using SQL server, Microsoft has release the 2.0 code for it. You can get more information at Scott Gu's blog.
http://weblogs.asp.net/scottgu/archive/2006/04/13/442772.aspx
If you want to start from scratch, they also have good resources at MSDN.
http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx
and
http://msdn.microsoft.com/en-us/library/6tc47t75.aspx
Once you have implemented your provider, you can then add the Membership user to the Items collection of the current web context to get access to it from your code. The non extended properties from the base base user class are also available on the Request thread like normal.
With the Microsoft release of the 2.0 version of the source code , we found it helped us alleviate some concerns that exist about reinventing. Another thing to consider for your implementations is based on your scenario, you can bypass implementing some of the code. An example of this would be the CreateUser code if you are hitting a back end system that already has the credential information.
It seems like you're relatively happy with your authentication process but you want to explore other options for session/settings.
My suggestion has to do with settings only (roles, preferences, etc.)
In my opinion, having to traverse the whole technology stack from UI to Business Tier to DB tier to DB is sometimes a bit overkill.
For data that isn't likely to change during a session, this adds a lot of overhead... There are potentially several data transformations happening (DB (Relational Format) -> ORM -> Web Service XML Serialization -> Web Tier deserialization).
You might consider a session system that doesn't rely on a heavy RDBMS system or on the ASP.NET Caching / Session model. There are options that are very performant and that scale well.
You could use RavenDB by Ayende Rahien (Built for .NET). Its main goal is to provide low latency, high performance access to schema-less JSON documents.
Using this solution, you would set up ravenDB in the web tier so that access to data is very quick.
The first time you authenticate and retrieve settings, you would store the userID and settings information in this session DB.
Every time you load your controller after that, the settings data is accessible without having to go back to the RDBMS.
This DB could also be used to cache other web related data.
As for security, the settings data makes it to the web tier regardless of the method you use. This solution would be no more or less secure than the other options (more secure than an unencrypted cookie). If you needed to, you could encrypt the session data - but that will increase your overhead again.
Just another one of the million options to consider.
Good Luck,
Let us know what you decide!
Patrick.
I am creating an Asp.net MVC application and I'm currently using the built in Authentication/Authorization code that comes with the sample MVC app. For the most part this is working ok and I kinda understand what's going on.
What's concerning me though, is that now I kind of have my users stored in two different tables across two databases. i.e. I have users in my App's database that represent the "Customer" entity in the application, as well as the "User" in the Authentication database that's used to log in someone to the app.
Should I take the logged in user's User.Identity.Name value and do look up in my Customers table or should I merge them into one table? What's the best practice way of handling this?
Please forgive my ignorance - this is the first time I'm working with a system like this.
Any feedback is greatly appreciated!
It's helpful to think of credentials and the records that associate a person to application data as two very different things. Depending on the application, your Customer may not have credentials to log in or you may have an administrative User that logs in but isn't related to your application data.
Separate credentials are also useful if Users access more than one application with different rights for each.
For these reasons, I'd keep Customer and User separate and look one up from the other where appropriate.
You can extend the .Net Membership Provider to take all the information you want and post back in a single model I think.
See this one ASP.net Profiles and Membership - Custom Providers or should completely I roll my own?
And this one How to implement ASP.NET membership provider in my domain model
I want to use an existing user and user group table that the forums use. I would prefer not to have to add any additional tables (other than what the forum already has).
I will be using MS SQL.
The forums are PHP which is why I want the .net site to handle all of the logic. The forum will use its own PHP logic as I will set and remove the cookies.
When the user requests a new password I would want to specify the text in the email.
I would want to set additional cookies when the user logs in (so that they are logged into the forums when they login to the site).
Is it possible to do this with the .net membership provider?
You can implement your own provider, see here. By this way you can choose any db schema you want, use your own password rules etc... It just takes you to overwrite the membership interface. Then you choose to use it in the webconfig, having 100% portability if you will change in the future...
I wouldn't. The membership provider stuff is a leaky abstraction. You have much more flexibility when implementing Users and Groups as fully fledged domain objects.