How to avoid using a membership provider?

Question

We are currently building an architecture for a thin client application. It must meet two basic requirements:

• The application must have a module design. Each module can have (and actually have) its own role system.
• Later, the application must be adapted to work with various databases on different machines.

We believe that Asp.NET MVC 3 is the appropriate platform for this task. To manage application data, we chose the latest version of the Entity Framework - its Data Providers batch and the Code First feature can save us a lot of time.

The part we are involved with is the user / role management system. We need to have some section of Global Administration to add users and give them access to the modules (only global admins can add users to the system, support "guy from the street" is not supported), and each module has its own administration section with its own administrators and roles. We already have a data model for storing everything that we need in an appropriate way, but we do not know how to properly access this data from the application.

Currently, we see two possible ways to solve this problem:

• To write your own membership providers and roles based on our DAL. None of our team has done this before, so we’re not sure if it’s worth it. The membership provider cannot offer such flexibility as applications, so some cries will be required.
• To break through some obsolete books to find out how the website administration system was organized before the membership providers were created where they were created.

Both of these methods are not elegant and not obvious to us, and it is not an easy question, which way to choose. We also believe that this may be a different solution (the reason for the architecture may be affected). Thus, we would be glad to see any suggestions related to this problem.

Answer 1

Well, finally, we decided to write everything from scratch, and it was easier that it was

• Add your own implementation of IPrincipal. Additional fields and completely different logic for the IsInRole () method to avoid writing your own attributes.
• Assigning our IPrincipal in the Global.ajax event to the user.

It was not difficult. Now we have all the necessary flexibility. No suppliers involved.

Answer 2

I personally would recommend using a standard membership provider to create and authenticate users first, and then as soon as you confirm that the user is not just a “street guy,” use your own architecture to make sure the authenticated user has access to the controller and actions they are trying to access.

The built-in membership provider takes care of a lot of nuances regarding user authentication, password storage, etc. He uses best practices to avoid brute force attacks, rainbow table attacks, etc. That was true and true.

But it looks like your permission structure for each module may or may not conform to ASP.NET role provider forms. If they do, then all is well and good, and it would be nice to implement a role provider for the role. But if your needs are out of the box, you probably would be better off just checking the rights manually at the point that suits you (controller, action, request filter, etc.).

Answer 3

I would advise you to use a custom membership provider. What for? Because it is a standard way and will save you a lot of work. It is not as difficult as I could see, and there are many resources like this one .

Answer 4

• To write your own membership providers and roles based on our DAL. None of our team has done this before, so we are not sure if this is the way to go. The membership provider cannot offer as much flexibility as applications need some screams to take.

This is very important if, by default, they do not provide the necessary functionality. If you already have a complex user system in your database, a user membership provider may be preferred.

This will add valuable experience to your team and you will be able to reuse most of the code in your next project. As @Randolf noted, there are many good resources for creating a customer membership provider, and I speak from some experience when I say that it is actually not that difficult. Everything is there, you just need to implement some methods.