ASP.NET MVC authentication using custom database instead of ASPNETDB?

Question

I already have a User table in my primary application database with an email address (which will act as the user name) and a password. I would like to authenticate using my database instead of the default authentication database (ASPNETDB).

Questions:

1. Is this a bad idea? Is it a huge can of worms to use my own DB for authentication?

2. How much work am I adding by doing this? I already have code for hashing the password and a query that will check if the email and password match the DB. So, I wouldn't be starting from scratch.

3. What would I need to do to use my database instead of ASPNETDB? I'm hoping this can be described in a few simple steps, but if not, could you point me to good source?

Update

I'm still looking for a little more detail here on my third question. Do I need to write my own MembershipProvider? What changes do I need to make to my web.config file? Will the [Authorize] attribute still work if I write my own solution? Can I use the automatically-generated AccountController with some minor modifications or do I basically need to rewrite the account controller from scratch?

Answer 1

1. No. And I would suspect most people do not trust that cruddy mechanism

2. Not much at all, especially since you have the table already.

3. Take a look at this for example: http://forums.asp.net/t/1250726.aspx

Answer 2

We're doing exactly this in one of our applications, and find it quite simple. We have an authentication service (called from the controller) that handles the mechanics of hashing the entered password to see if it is a match, then simply returns a bool for a method we call "IsValidLogon".

In our case, the purpose was to keep the management of what should be a pretty trivial task as lightweight as possible.

We bascially ignored ASPNETDB entirely. If we get a valid response from our user/password check, we simply call the standard FormsAuthentication.RedirectFromLoginPage(username, createCookieBool);

Hope that helps.

Answer 3

Hi,

just building the same, so answer to 1 must be NO :) I'm using the standard asp.net forms authentication, where i use the FormsAuthentication.RedirectFromLoginPage(username, createCookieBool) method to log a user in. I gave a user a unique guid (you can use any other user id) and i'm storing it in the UserName parameter along with the username (to display on the masterpage: Html.Encode(Page.User.Identity.Name.Split("|".ToCharArray())[1]))

In each controller/method in which i must know which user is logged on (via User.Identity.Name, split the string and get the userguid). Also i decorate those routines with the [Authorize] attribute.

Answer 4

It's quite simple, you need to derrive MembershipProvider and implement the ValidateUser method. Take a look at this post. I'm using custom membership provider with Postgres and MVC just fine.

Answer 5

I'll answer your updated questions:

Do I need to write my own MembershipProvider?

If you (a) want to continue using Forms Authentication, and (b) have an authorization table structure that doesn't follow the same conventions as the ASPNETDB, then yes. If you don't need FormsAuth (see below), then you can do away with the MembershipProvider entirely, but I wouldn't recommend it. Or, if you're using the exact same security tables as ASPNETDB but just want to point it to a different database, you can continue using the default provider and simply change its configuration.

What changes do I need to make to my web.config file?

If you are using your own custom MembershipProvider, then you need to register it in the <providers> section of the <membership> element and change the defaultProvider property. If you are using the standard AspNetSqlProvider then you probably just need to change the connection string.

Will the [Authorize] attribute still work if I write my own solution?

Yes, if you stick to Forms Authentication (either use the AspNetSqlProvider or write and register your own membership provider). No, if you abandon Forms Authentication (again, not recommended).

Can I use the automatically-generated AccountController with some minor modifications or do I basically need to rewrite the account controller from scratch?

You should rewrite the AccountController anyway - don't leave demo code in a production app. But if you must - yes, the AccountController will work under the same conditions as above.