Should we develop a custom membership provider in this case?

Question

Summary

Long story short, we've been tasked with gutting the authentication and authorization parts of a fairly old and bloated asp.net application that previously had all of these components written from scratch. Since our application isn't a typical one, and none of us have experience in asp.net's built in membership provider stuff, we're not sure if we should roll our own authentication and authorization again or if we should try to work within the asp.net membership provider mindset and develop our own membership provider.

Our Application

We have a fairly old asp.net application that gets installed at customer locations to service clients on a LAN. Admins create users (users do not sign up) and depending on the install, we may have the software integrated with LDAP.

Currently, the LDAP integration bulk-imports the users to our database and when they login, it authenticates against LDAP so we dont have to manage their passwords. Nothing amazing there.

Admins can assign users to 1 group and they can change the authorization of that group to manage access to various parts of the software.

Groups are maintained by Admins (web based UI) and as said earlier, granted / denied permissions to certain functionality within the application.

All this was completely written from the ground up without using any of the built in .net authorization or authentication. We literally have IsLoggedIn() methods that check for login and redirect to our login page if they aren't.

Our Rewrite

We've been tasked to integrate more tightly with LDAP, they want us to tie groups in our application to groups (or whatever types of containers that LDAP uses) in LDAP so that when a customer opt's to use our LDAP integration, they dont have to manage their users in LDAP AND in our application.

The new way, they will simply create users in LDAP, add them to Groups in LDAP and our application will see that they belong to the appropriate LDAP group and authenticate and authorize them.

In addition, we've been granted the go ahead to completely rip out the User authentication and authorization code and completely re-do it.

Our Problem

The problem is that none of us have any experience with asp.net membership provider functionality. The little bit of exposure I have to it makes me worry that it was not intended to be used for an application such as ours. Though, developing our own ASP.NET Membership Provider and Role Manager sounds like it would be a great experience and most likely the appropriate thing to do.

Basically, I'm looking for advice, should we be using the ASP.NET Membership provider & Role Management API or should we continue to roll our own? I know this decision will be influenced by our requirements so I'm going over them below

Our Requirements

Just a quick n dirty list

• Maintain the ability to have a db of users and authenticate them and give admins (only, not users) the ability to CRUD users
• Allow the site to integrate with LDAP, when this is chosen, they don't want any users stored in the DB, only the relationship between Groups as they exist in our app / db and the Groups/Containers as they exist in LDAP.
• .net 3.5 is being used (mix of asp.net webforms and asp.net mvc)
• Has to work in ASP.NET and ASP.NET MVC (shouldn't be a problem I'm guessing)
• This can't be user centric, administrators need to be the only ones that CRUD (or import via ldap) users and groups
• We have to be able to Auth via LDAP when its configured to do so

I always try to monitor my questions closely so feel free to ask for more info. Also, as a general summary of what I'm looking for in an answer is just. "You should/shouldn't use xyz, here's why".

Links regarding asp.net membership provider and role management stuff are very welcome, most of the stuff I'm finding is 5+ years old.

Answer 1

Security in the context of your problem involves two separate operations: authentication and authorization and those are divided in .NET into MembershipProviders and RoleProviders. I would strongly recommend using both (meaning custom or built-in) to do your authentication and authorization. Doing so, provides a path to upgrade should you later find better tools to do the job and makes it easier for other developers to understand the security.

Now, for authentication, I would, as others have stated, use either the SqlMembershipProvider or the ActiveDirectoryMembershipProvider. My experience has been that in 99% of the cases the ActiveDirectoryMembershipProvider provides enough functionalty for what is need when working against a full AD store (i.e. not ADAM aka ActiveDirectory Application Mode). I have had problems with the ActiveDirectoryMembershipProvider in multi-domain situations but in general finding a way of using it rather than rolling your own is much better. Similarly, the SqlMembershipProvider for authentication, works well and scales well.

Authorization however is an entirely different kettle of fish. This is really where your pain will be felt. First, there is no "ActiveDirectoryRoleProvider". That means if you want to integrate with AD groups, you have three choices:

1. Use AzMan
2. Do it yourself via a custom RoleProvider
3. Find someone that has done it for you.
4. Use ADFS or Microsoft's new Federated Services

Choice 1: AzMan AzMan (Authorization Manager) (See also Windows Authorization Manager) is a tool Microsoft wrote to manage application authorization. AzMan has some nice features to it:

1. It can link your roles to AD groups (or Windows groups)
2. It can be stored as a file so you can keep it with the application.
3. Nicely breaks up authorization into tasks, operations and roles.
4. Comes with a separate administrative tool
5. The 2008 version will interact with SQL authentication stores.

The catch is that AzMan can be a bear to develop against and understanding the tool is not for someone that isn't experienced. I found that documentation was scant but that was a few years ago. In addition, the AuthorizationStoreRoleProvider does not support Tasks even though AzMan itself does. Tasks are the most granular things that can be done and are group into Operations which themselves can be grouped into Roles into which users or AD groups can be dropped. Documentation has gotten a little better. I do know that when I last worked with AzMan, it's lack of inherit interaction with a database authentication store made it a bit of a pain to work with.

Choice 2: Write your own RoleProvider

This can be a painful experience with LDAP. You would only need a custom RoleProvider in the case where you wanted to query against AD groups and did not want to use AzMan if you planned on using the SqlRoleProvider in non-AD environments.

Another alternative which I have used, is to manage roles in the database and allow the MembershipProvider to be whatever it wants. This still entails writing a custom provider (but a significantly simpler one) and it makes it easy to move the application into an AD environment with little mess. If you store roles in the database and if you want to allow administrators to associate multiple levels of groups to your roles, then you'll have to write that into your custom RoleProvider.

If you plan on using the SqlRoleProvider you also can run into a few issues. If you use the SqlRoleProvider with the SqlMemberProvider in a single application environment then it will work quite well and is very easy to setup. However, if you have multiple applications that you want to authenticate against a single store, then the SqlRoleProvider will not work properly in all cases out of the box without modification.

Choice 3: Find someone that has done it for you.

Specifically, I mean find someone that has developed an ActiveDirectoryRoleProvider. You can easily Google for various choices but I have not used them and would want to pour over any code that anything to do with security in my application.

Choice 4: Active Directory Federated Services

Microsoft has really been pushing this solution which does promise single sign-on if you can get it working. The catch to this solution is getting it setup especially between you and a partner.