Develop Reference

MVC4 Extend SimpleMembership

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?

Is the default authorization system in an ASP.NET application good enough?

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.

What are the pros and cons using the asp.net membership?

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.

Defining different roles in my ASP.Net application

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.

ASP.NET: Permission/authentication architecture

I am looking into building an authentication in my ASP.NET application with the following requirements.
A user has exactly one Role (i.e. Admin, SalesManager, Sales, ....)
A role has a set of permissions to CRUD access a subset of existing objects. I.e.
"Sales has CREAD, READ, WRITE permission on object type "Products" but not DELETE"
Somehow I like the permissions to be in a hierarchy with inheritance so that I for i.e. Admin don't need to specify all available objects.
The system must quickly be able to answer the question "Does user X have permission to do Y to object Z"
All database managed (MSSQL), implemented in C#/ASP.NET
I would like to get feedback on these requirements? Any ideas how to implement this using ASP.NET framework(as much as possible)? (However, I'm also interested to know how this can be achieved without Memberships)

I think what you need to do here is implement a set of permissions query methods in either your business objects or your controller. Examples: CanRead(), CanEdit(), CanDelete()
When the page renders, it needs to query the business object and determine the users authorized capabilities and enable or disable functionality based on this information. The business object can, in turn, use Roles or additional database queries to determine the active user's permissions.
I can't think of a way to declaratively define these permissions centrally. They need to be distributed into the implementation of the functions. If you want do improve the design, however, you could use dependency injection to insert authorizers into your business objects and thus keep the implementations separate.
There's some code that uses this model in Rocky Lhotka's book. The new version isn't in Google yet.

I think one of the best implementations that I think will fulfill your requirements is documented here. The only issue is that this hooks into NHibernate, but you can use this as a template to create your own permissions implementation and simply hook into your own event model rather than that of NHibernates Interceptors.
I am working on such a system myself and will blog it once I am happy with it.

The membership API provided since ASP.NET 2.0 should suit your requirements well. The only thing I'm afraid it doesn't directly support is hierarchical roles. However you can easily use normal role based security with another manually written hierarchical roles table to achieve the required things.

You can read on how to set up ASP.NET Membership here: http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx
It allows you to group folders / pages etc into Groups / Users. I think you will find this sufficient!
The hiarchy is easily managed by extending the generated databases and procedures.

I would build the user/role relationship so users can have more than 1 role. I see a 1-1 relationship and I get nervous because I know that even if we don't see a need for it now, someone is someday going to want someone to be both a Sales user and a Customer Service user.
In our customer system, we use roles to layer on stuff like "delinquentCustomer." That way, the original permissions are still valid--as soon as they pay their bill. Worth considering this approach.