0

I'm building a couple of ASP.NET MVC websites that will share a database (because they share data under the hood). That said, logins between sites will not be shared at the moment. For reference, I'm using NHibernate for data access with SQL Server under the hood (currently).

As currently laid out, the system has tables for Sites, Roles, Users, and Rights. Sites have sets of users, rights, and roles. Users can be in many roles. Roles have a set of rights. Users will be able to sign in with a username and password, but I don't want to paint myself into a corner - I might want them to be able to use a google or facebook login later.

Now, I'm a little confused as to which path to take with regard to securing the site. I'm not enamored of the old school membership and role providers for several reasons. Chief among these is that I won't be restricting very many things by roles; things will be restricted based on user access rights. I'm looking at the following few scenarios for authentication. 1) I want to be able to specify rights required to use a controller method via an attribute. 2) I want to be able to quickly query and see if a user is in a particular role or has a particular right.

So, I actually have a set of questions, but they are kind of intertangled. First, what should I do? Just a custom authorization attribute? Second, what's the workflow on login and the like? What are the steps required for this to work properly and securely?

I realize these are sort of noobish questions, but in the past I've gotten by with the old provider way of doing things. I don't particularly care for that and would really like some better suggestions. So I guess everything old is new again for me.

Will Gant
  • 583
  • 5
  • 21
  • Membership and Roles are great as they leverage plenty of what we need, you can always create a [custom Membership and Roles](http://stackoverflow.com/questions/5701673/custom-membershipprovider-in-net-4-0/5702000#5702000) and you do know that a user can have n Roles right? so, if you create a Role per `controller`, it will be easier for you to accomplish what you need. – balexandre Jul 14 '13 at 21:27

1 Answers1

0

I would flee the Membership provider from MS like the pest. It was already badly implemented when it came out with .NET 2.0, and the recent refresh is no better.

Roles, Users, ..that's not bound to the Membership provider, you can use those on your own. Set up Authentification, create a httmodule that handles said Authentification (a simple userId for the Context.User.Identity suffices)

All you need is a User that derives from IIdentity and in your httmodule 

string[] roles = new[] {"Admin", "CoolDude"};
HttpContext.Current.User = new System.Security.Principal.GenericPrincipal(user, roles);

..and now in your mvc controller simply add the necessary authentication attributes, game played !

Make custom roles, custom mvc attributes, or query if a user is in a specific role directly

if (HttpContext.Current.User.IsInRole("Admin")) { ...
Robert Hoffmann
  • 2,366
  • 19
  • 29
  • There is nothing "badly implemented" about the membership provider, although there were a few decisions made that were not ideal (global static instances, for instance), but these are at worst annoyances. 99% of people that try to implement their own username/password management will do it insecurely, and I consider using a default provider to be far better than doing it yourself, unless you know what you're doing. – Erik Funkenbusch Jul 15 '13 at 00:13
  • I'll have to go with a different storage mechanism anyway. I don't really want the thing going around my business layer to create and validate users and I want the advantage of all the caching and the like that NHibernate offers. I guess I could implement a custom provider. I just don't know if that's still the best idea. – Will Gant Jul 15 '13 at 01:11
  • @WillGant - I wouldn't necessarily implement a custom provider, in fact in most cases I think a custom provider is the wrong answer, because the .net Membership is designed to be a reusable and generic system. The thing is, most people really don't understand that Membership is just a system to store and validate credentials. That's it. Related to it are the Roles and Profile systems, as well as the FormsAuthentication system. These are all different things. At it's heart. .net uses the IIdentity and IPrincipal classes, of which implementing your own versions of that might be beneficial – Erik Funkenbusch Jul 15 '13 at 06:14
  • Yes, you don't need a provider at all. Just implement your database as usual, and make sure your User or something derives from IIdentity, once that done you just have to play around with a custom httpmodule (which is like less than 20 lines of code) that handles auth and add all the roles n stuff you want to use, and from there you can use all the auth attributes already in place in mvc. IIdentity, IPrincipale, Users, and Roles. That's all you need. – Robert Hoffmann Jul 15 '13 at 07:32
  • This article pretty well explains the shortcomings of the MemberShip/SimpleMemberShip providers http://brockallen.com/2012/09/02/think-twice-about-using-membershipprovider-and-simplemembership/ – Robert Hoffmann Jul 15 '13 at 07:44