I am looking at migrating an old app to MVC4 but can't yet modify the database. The existing database already has it's own user / group / membership tables setup (in a rather quirky way might I add, but it works).
With the MVC3 style MembershipProviders I could roll my own extending what I needed to login, check role permissions, modify user attributes etc. but I'm at a loss as to how to achieve this with MVC4 and it's SimpleMembership and then how to use OpenAuth alongside it as an alternate way to login.
I've been looking around but there seems to be very little content online yet regarding it, any ideas?
I don't require a SimpleMembership implementation, if anyone is aware of another similar provider that would do too.
SimpleMembership is just like its name: simple. So if you want to extend the membership provider to meet your complex requirement of roles and membership, it's not a good choice. If you do really have to upgrade your app to mvc4, just do it, then reuse the ASP.Net Membership that exited in your app. It's still running properly on mvc4.
One thing to try is to just use SimpleMembership and add as many roles as you need to make up for your current "attributes". Depends on what you mean by "attributes". If you just want to add additional columns to the UsersProfile table, it's pretty easy to do. And then the SimpleMembership API can access those new columns just as it does the built-in ones in a default MVC4 Internet App. project.
Have you viewed this SO thread?
Related
I'm writing an intranet application using MVC4 and designed as SPA application.
The application assumptions are that there is no SSO and the users will be stored at the SQL DB.
I'm not interested in open authorization with external accounts. (As demonstrated in the SPA template).
The users will have some custom fields (Mobile, Email etc.)
Most of the actions are limited to certain roles.
I'm looking for the most built-in mechanims the achieve it.
I want to use the AutorizeFilter and avoid any custom implmenetations if possible.
Mention that some of the actions are WebAPI in REST Services in the application.
I didn't find a good "end to end" article that demonstrates how to implement and manage users and roles.
Is there a template that comes with login views, models etc. and is there supporting UI for managing users and roles?
I'm using MVC 4, EF 6.0.1 amd can use the most advanced components. (No limiting legacy :-) )
Any leads will highly appreciate.
Thanks in advance!
Yaron.
In a recent similar project (MVC4, intranet, EF CF) I had a STI on the users hierarchy, and the discriminator field (which in fact is the "type" of the entity) was used to manage permissions. I made like 3-4 simple filters (like "AdminFilter", "ManagerFilter") and authorized the actions using those filters. It was really quick.
I'm looking for the most built-in mechanims the achieve it.
I've looked for something like that, but didn't find it. Well, maybe I didn't look for it that much.
I hope it will help someone...
At first I have read this great article:
http://blog.longle.net/2012/09/25/seeding-users-and-roles-with-mvc4-simplemembershipprovider-simpleroleprovider-ef5-codefirst-and-custom-user-properties
I have used simple membership and role and then used the role name as a key in an entity that extends the role with extra information.
I didn't use the Authorize filter and created custom filter that implements "Feature based authorization".
The main idea is that the authorization meachnism is a set of features.
A feature is an activity that some roles can perform while others can't.
This is a much better architecture that is easier to manage mentain and extend.
I'm learning ASP.NET MVC 3 to build a web application. I've followed a couple tutorials teaching the Entity framework, Razor, MVC, etc. One thing I can't find much about though is how to do authentication and authorization. In the tutorials I can find, it basically goes
Create an "Internet Application" project. The authorization system is already there so you don't need any code. Now use an ASP.NET settings panel to set up user roles and slap [Authorize] everywhere.
I understand the system it starts you off with is called ASP.NET Membership. Is it common to just stick with that for your authorization?
I've been using Code First to do models and databases -- is there a way I can create my own user models, have ASP.NET create the database, and use that for membership? How tough is it to customize user models (for example, if I want some user roles to have some information stored with their membership, but not others)?
Are there any tutorials that go through ASP.NET Membership in detail rather than just starting with whatever the project template spits out? For example, implementing it in an empty project?
It depends on the needs of your application. You will find the provided model has some limitations, but if you only need basic user/role management then it might suffice. Personally, I've always found it a bit too inflexible for my liking, but if it does what you need for the application your building, don't waste your time reinventing it.
Hope this helps.
You can extend the default membership behavior by adding a role provider which allows you to group users into one or more roles.
Furthermore you can extend the user's profile information to store additional information (although not specific to a role, so all profiles will have a slot for role-specific information). See this article by ScottGu for how to extend a profile: http://weblogs.asp.net/scottgu/archive/2005/10/18/427754.aspx.
I'm building a new website and a friend suggest to me to use the asp.net membership for the authentication process (login, registration, password recovery, etc..).
I saw that everything is stored in an XML file.
I would like to know what are the pros and cons using the membership instead of to build something from scratch.
The MS login solution consists of several parts.
Authentication - "Who can access your site"
Forms Authentication - This basically creates a secure cookie that says "I'm authenticated!" on every request. Without this, users would have to log in every single page.
Pros: This works well
Cons: None - use it
Membership - This is how you store your users and their passwords, and validate user credentials. There are several ways to approach this:
Using the SqlMembershipProvider - Microsoft gives you a database to store users/passwords in securely, and gives you a way to authenticate credentials.
Pros:
Less/no custom code to maintain. Works "out of the box"
Works with Membership controls and API
Cons:
You have to use a Sql Server and use their database schema. (not a problem IMO)
No control over how passwords are initially generated. They're long and ugly
Steeper learning curve as you get familiar with the technology
Creating a custom MembershipProvider - You can inherit from MembershipProvider to customize where and how you store your data.
Pros:
You get Encryption/Decryption of passwords for free
Control over where you store your users and what the data looks like
You can still use the Membership controls and API
Cons:
Have to implement your own storage solution
You have to write, debug, and maintain a lot of custom code
If you add additional functionality, you have to cast the provider to use it
Creating your own Authentication scheme
Pros: Complete control
Cons:
You create everything, but have to debug/maintain everything.
You have to control security over credentials yourself.
Can't use Membership controls (This isn't a big loss as the controls are pretty simple to replicate)
Can't use Membership API
Authorization - "What can the users do?"
Roles - Roles control what the users can do via the authorization mechanism provided by the web.config and also works with security trimming on the sitemap.
Using the SqlRoleProvider - Microsoft gives you a database to store roles
Pros:
Works with the web.config
You can assign more than one role to a user
Cons:
Roles are just a string, no "hierarchy of permissions" support. This can make it difficult to create rules around which users can edit other users.
Creating a custom RoleProvider - You can inherit from RoleProvider to customize where and how you store your data.
Pros: Works with the web.config
Cons:
Have to implement your own storage solution
Still just a string and are as limited as the previous solution
If you don't implement it correctly, it could do a lot of database calls.
Creating your own Authentication scheme
Pros: Complete control - Just do custom checks on your page and error/redirect as necessary
Cons:
Doesn't work with the authorization mechanism provided by the web.config / sitemap. Practically this means that adding a page to a folder (such as /Admin) no longer guarantees security on that page.
It's important to note that the Membership and Role providers can be chosen or customized independently of each other. I would personally recommend using the SqlMembershipProvider if you can and evaluating your options for the Role Provider.
I dont like to use Membership Provider.
This is util when the scenario is "standard", but in cases that you need more custom rules, I think that dont works well. Appear "workarounds".
And not need store in a XML, exists another solutions (database, for exmaple).
Cons:
Your preferred datastore might not be fully supported out of the box
It might not match your current or future requirements
You might not fully understand the intricacies of how it works (over something you built yourself)
Pros:
You might save time compared to rolling your own.
Personally... if this is a serious project I would roll your own (but of course keep forms authentication). In my experience a lot of these 'out of the box' features from MS are rather half-assed.
The nice thing about ASP.Net Membership is that you can use as much or as little as you like - you can store user data in various forms (as others have mentioned), or you can just use ASP.Net Membership to handle session authorisation and page protection.
For example, you can go the whole hog and use the login control, the SQLMembershipProvider back end and just let ASP.Net Membership do everything end to end.
Or you can store your own usernames and passwords, in your own database table, authenticate the supplied details yourself and then simply just use "FormsAuthentication.RedirectFromLoginPage()" to tell ASP.Net membership that the user is authenticated, and have ASP.Net Membership then control access to pages.
ASP.Net Membership is tried and tested, its used by thousands of sites inside and outside of Microsoft, so you know the code works and works well. If there is an issue, then there are many implementations out there that will find it. Your own approach just has one user...
Actually, everything is not nessicarily stored in an XML-file. You can store the membershipdata in several ways, including a database.
You can also use the ASP.NET roles/membership library as a starting point for rolling your own. There are a few tutorials on doing this around the interwebs.
The pros with using the built-in functions is that the ASP.NET membership gui-controls more or less "just work".. ;)
In my opinion, the .NET membership providers are a great way to go regardless. I have written quite a few large applications using them. If your architecture is good, it's fairly simple to add functionality and change data in future releases.
Here's a bit of context to frame my answers. The membership/role/profile solutions in .NET consist of two parts: the framework and the providers. The framework consists of the methods and information your program will interact with. The providers determine how the data will be stored.
I find that the framework is excellent. There isn't much that you can't do regardless of how you want to interact with it. The default implementations do give you a lot for free. Any lack of functionality is further mitigated as a con if you are using good coding practices. See the starter ASP.NET MVC application for an excellent example of wrapping the membership framework.
The data never seems to work out the way you want, but it's nothing you can't work around. First as folks said, there are a bunch of providers shipped with .NET. And this is also where implementing your own provider comes into play. We usually start by subclassing SqlMembershipProvider. If something doesn't work the way we want, we override it. And changing the data tables at a later time if needed is not terribly difficult.
Using what already exists always seems to let us get going quickly and adapt as needed. In truth changes to this code don't happen often. Using the Microsoft solution at the beginning might not result with the prettiest piece of work, but it gets the job done quickly and lets you move on to solving important problems.
We are developing an ASP.NET MVC Application that currently uses it's own database ApplicationData for the domain models and another one Membership for the user management / membership provider.
We do access restrictions using data-annotations in our controllers.
[Authorize(Roles = "administrators, managers")]
This worked great for simple use cases.
As we are scaling our application our customer wants to restrict specific users to access specific areas of our ApplicationData database.
Each of our products contains a foreign key referring to the region the product was assembled in.
A user story would be:
Users in the role NewYorkManagers should only be able to edit / see products that are assembled in New York.
We created a placeholder table UserRightsRegions that contains the UserId and the RegionId.
How can I link both the ApplicationData and the Membership databases in order to work properly / having cross-database-key-references? (Is something like this even possible?)
All help is more than appreciated!
In my opinion, you should be able to integrate your database with the standard aspnet_db reliably, but I would advise against duplicating or replacing the aspnet_users table.
That is the focal point of all the providers that use the aspnet_db schema, including custom providers that may augment but do not implement custom replacement.
To maximize reuse of strong tested infrastructure code in the provider stack/API it is best to go with that flow.
You will want to be very attentive to any modified membership core functions and ensure that the way your new constraints behave in an expected fashion in each case.
The facet of the membership story that I have found needs the most attention is deleting a user, and a simple modification/addition to the delete user sproc can manage this capably.
It sounds like you might need to create your own customized Membership Provider. You can probably (not positive here) extend the existing one so you don't have to completely reinvent it. Here is a video from ASP.net that describes how to do that. Google "asp.net membership provider" for tons more.
You can try rolling your own membership or just extend is like Dave suggests.
Create your own [Users] Table which can be populated based off the aspnet_Membership table. So therefore you could have more control over it.
You could also just implement a more involved Profiles system. The .NET team has improved the way profiles are stored now, so instead of "blobicizing" them, you can set them up to be stored in an actual table now [thank god].
Table Profile Provider
If you find the right articles, it's really easy to extend the membership provider to allow for extra functionality. I've moved my users table to my main SQL server table and have written my own role manager that gets values from a separate table. What it sounds like you need to do is to set up a table in your users DB with the location of each user, then create a method on the user object something like "GetLocation()" that returns the user's location from the DB, you could then user that to filter your data from your main DB. Here's a few articles I had kicking aroundin my bookmarks, see if they help, if you have a look on the main ASP.NET site or google for membership provider extending articles, there are plenty around.
http://msdn.microsoft.com/en-us/library/ms998347.aspx
https://web.archive.org/web/20211020202857/http://www.4guysfromrolla.com/articles/120705-1.aspx
http://msdn.microsoft.com/en-us/library/aa479048.aspx
As the others have pointed out there are many good resources available that can help you with creating your custom provider using the existing database.
It looks like you are headed in the right direction with mapping tables. I think the one piece you are missing is Distributed Queries. This link is specific to Sql Server 2008. There is a link there to the documentation for Sql Server 2005 if that is what you are using.
I have a website that's sort of a Craiglist type app.
In my Database, should I create a table called UserRoles, and assign the UserRoleID as a Foreign Key to every user created? 1 for Admin(Complete Priveledges), 2 for Moderator, 3 for Normal User, etc.
Also, inside of my ASP.Net application, say I have a UserControl. Inside of that user controls method, should I ask if User.ID = "1" make a button X.Visible = True?
Say if the currently logged in user is an Admin, make a little red X appear so the Admin can easily delete a listing, etc.
Or is there a more established way to do this?
You have the right general idea of a roles provider there. Role providers give a user some level (or perhaps multiple levels) and then in your code you can validate the current user's level when displaying content and evaluating inputs.
If you are using your own system then what you have described above is a perfectly reasonable approach to authentication and authorization. However, if you are using the ASP.NET built-in MemberShipProvider and RoleProvider (which you probably should be!) then there are many tutorials on getting those up and running. Personally, I would recommend using an existing provider over reinventing the wheel, but that's just me. You'll find that the built in providers are very comprehensive and simple to use.
Roughly speaking that is how you would do it.
You should probably take a look at .Net Membership as it already provides most of the leg work to get this done.
Also rather than writing user.RoleID == 1, all over the place consider writing some methods/properties to answer the question for you.
e.g.
if(myuser.IsAdmin)
{
....
}
or
if(myuser.HasRightsTo(Rights.DoX))
{
....
}
ASP.NET 2.0 introduced Membership. It makes maintaining users, roles, and profiles rather simple. I would recommend using the default SQL implementations.