2

Background:

I'm incorporating the SqlMembership provider into an existing system where I'm building a web front end. The Membership database will be kept in a separate database.

Beyond the login account, there's an additional mapping between the accounts that needs to be in place in the main database in order for an account to be able to log in.

Let's say that this table gives the user the right to use the system.

My question:

I would like to somehow incorporate this into the provider. Is it possible without too much work? (Or is it better to keep it in the AccountMembershipService class?) Actually regardless, I'm very interested in learning how to put additional login requirements into the provider.

I'm asking this because when I've been looking at creating a custom membership provider earlier it seemed at that time a little bit overwhelming.

In other words:

I want to understand how to extend the Membership Provider classes in general and how to extend the login method (ValidateUser) in particular.

Given the sample ODBC implementation It looks like one simply could subclass the default provider and override ValidateUser calling base.ValidateUser as the first step. However it may or may not be that simple, and I'd be very happy to hear any first hand experiences from implementing or extending membership providers.

Carl R
  • 8,104
  • 5
  • 48
  • 80

2 Answers2

0

In order to extend the membership provider make you own tables with one to one relationship with the main database and handle additional requirements through this table. Also while implementing and extending the default membership provider you may need to store extra information in authcookies you may get additional information from here , here and here

In GetUserCredentials you will do your stuff for additional checking and RoleID is some dropdown on your login page that you will receive in the post method of sign in.

FormsAuth.SignIn(userName, rememberMe);
            ApplicationRepository _ApplicationRepository = new ApplicationRepository();
            MembershipUser aspUser = Membership.GetUser(userName);
            SessionUser CurrentUser = _ApplicationRepository.GetUserCredentials(aspUser.ProviderUserKey.ToString(), RoleID);
            if (CurrentUser == null) 
            {
                ModelState.AddModelError("_FORM", "Invalid Role ");                   
                FormsAuth.SignOut();
                return View("signin");
            }
Community
  • 1
  • 1
Tassadaque
  • 8,129
  • 13
  • 57
  • 89
  • I'm not so much interested in what to do with the database or the auth cookies, but rather [how to extend](http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx) the [membership provider class](http://msdn.microsoft.com/en-us/library/system.web.security.membershipprovider.aspx). As I said I've found it an overwhelming task earlier, so I'm looking for examples or howto's for adding additional login requirements. – Carl R Jun 13 '11 at 21:22
  • As I understand from your additional login requirements you want some role based resource restriction. e.g. in case of menu one group of user can see the whole menu and other may have limited access Is it what you are looking for or something else. – Tassadaque Jun 14 '11 at 04:24
  • No, i want to do some checks during login, while avoiding a spaghetti kind of mess in the login controller. Or as the heading says: **"Checking additional requirements during login?"**. What checks is irrelevant. Where and how to extend the membership provider classes is what I'm asking for. – Carl R Jun 14 '11 at 06:30
  • Oh, but that's exactly the kind of solution that I want to avoid. I want to learn how to extend the Membership provider. – Carl R Jun 14 '11 at 06:58
  • you asked without much work. i think you have to write some code mentioned here http://msdn.microsoft.com/en-us/library/ms366730(VS.80).aspx – Tassadaque Jun 14 '11 at 07:25
  • Thank you for taking time discussing. I have however read the docs, but I'm looking for guidance from previous experience implementing custom providers and it's implications. Thanks. – Carl R Jun 14 '11 at 07:51
0

I wanted to do something similar, one of the requirements was to use an Oracle DB, so I implemented the OracleMembership provider, hence I could not waste my time rewriting the hole oracle membership provider (it works pretty fine), the second requirement was to use a custom authorization legacy system. So I realized that the Internet Application template which comes with the MVC 2 or 3 comes with a small implementation of the security for the site, specifically take a look on the AccountMembershipService class. You could move all of these elements out of the MVC app to a separate assembly so you could use it even on a client implementation. The AccountMembershipService uses the Membership provider as the underlying authentication system with the option of using FormsAuthentication.

So I recommend you to take a look on that implementation. You could put your additional authentication code there so your application would stay cleaner and your don't need to re-invent the wheel and you have the chance to add your own code.

best regards

Rodrigo Caballero
  • 1,090
  • 1
  • 15
  • 27