Forums

Support Forum DNN General Dis... Membership Prov... Building your own Membership Provider for DotNetNuke and ASP.NET 2.0

12/12/2006 4:38 PM

	Henry Kenuam
29 posts

Re: Building your own Membership Provider for DotNetNuke and ASP.NET 2.0

Daks,

Let me try and respond to your questions individually.

My biggest question is:
Is it possible to completely eliminate DNN for storing user information (roles / profiles / membership) and keep this all in the remote datastore. One of the requirements is that the website (dnn) know/store absolutely nothing about users. So its key that I can keep them 100% seperate.

I've not tried to eliminate them entirely but I believe it is possible. For example, your membership provider would not read/write to any DNN tables. Since this would be handled internally your implementation you wouldn't implement it.

Other questions are, for authentication, our authentication is more than a simple user / pass combination. There is a possibility that a username, password and an identity would be passed. In the case where a higher privileged user would "log in as" another user he can manage. The user would use their own user / pass combination, and the user they are loggin in as username. The system automatically will authenticate the primary user as himself with his own credentials, but then "impersonate" the supplied secondary username.

I have actually had the need for the same functionality in other sites (to impersonate a user) so that I may see data that the user sees. This is not something that is built into DNN natively but it is possible to build "Impersonate" functionality on one of your Admin controls. In my case, ALL code that we had written called a property on the superclass (control) for all our module controls called UserId (or something) and inside that method we were able to test to see if you were in an impersonating mode and return the correct userid. This was a clean way to handle this but we built that in from the beginning. In otherwords, your modules couldn't call UserController.GetCurrentUserInfo or equivalents. Developers had to use the inherited property in their controls they developed to reference the user. The other half is implemented a control that allows you to select a user to impersonate after the admin has logged in to the site. This functionality is pretty straight forward but you will need to store information regarding the mode your in i.e. IsImpersonating and the Id of the user.

Many of the original methods / properties (and objects) in the dnn providers that get called from dnn core do not match up very well to what we have currently, and what we have need for. I think that this will causing problems for us when dnn kicks for data and calls a method that is (since its the core calling) doesnt fit our information / format... I would think that there is a way to map our data to their format, but... Its causing massive brain ache to go through everything... Replacing the user controllers and everything inside of that is messing with core, and doesnt seem the correct approach.

Your correct, replacing the controller classes isn't the correct approach. For example, the UserController.GetUser() method forwards the request to the MembershipProvider which is defined in the web.config (you may already know this). So the providers are the "swappable" pieces. This can be very very frustrating but if you setup a web site and add a reference to the source projects you can set ALOT of breakpoints and get a pretty good understanding of which methods get called and what you would need to replace. I would recommend referencing the membership, role and profile provider projects.

/shrug... I feel like I am spinning my wheels trying to fit a square peg into a round hole... However everything I read tells me that dnn was built to allow this type of functionality... Did we just create something that was so far off the norm that we can not use what dnn has to offer?

Other than the impersonate functionality which can be done it doesn't sound like it.

Henry Kenuam
Engage Software
St. Louis, MO
314.966.4000

The leading provider of DotNetNuke support, training and custom development.

12/13/2006 9:18 AM

	Daks
2 posts

Re: Building your own Membership Provider for DotNetNuke and ASP.NET 2.0

Good information, and really a brilliant way of handling the impersonate, I hadnt thought of doing it after authentication since our original app did everything before hand... Thats what I get for closing my mind to other (better suited) methods! ;)

So I guess it all comes down to just getting down and dirty with things again. Like you said, setting the break points and mapping what you see what is called from dnn and taking care of those pieces.

Thank you for the article and the response, DNN'ers are some of the best folks in the industry =)

Daks

12/14/2006 8:18 PM

	KWGainey
1 posts

Re: Building your own Membership Provider for DotNetNuke and ASP.NET 2.0

Thanks for putting this excellent resource together! I'm working on creating a custom membership provider and running into some problems. I'm on 4.3.5. My goal is to create a custom provider to hit a different database to take care of the authentication and authorization pieces. After reading this article, I thought my main job would be to update the new SqlDataProvider.vb file to contain the code I need for each method to hit the new database.

I can go through the steps (drop reference, copy AspNetMembershipProvider, rename files, add project reference) and rename everything fine. However, SqlDataProvider.vb in the SqlDataProvider folder, as copied from the AspNetMembershipProvider folder isn't used or referenced in my new custom provider project. The DataProvider.vb file also needs to be modified so that it's not trying to cast to a DotNetNuke.Provider.AspNetProvider type object in the CreateProvider method. Also, it looks like I will need to add a custom <data> section to web.config also so that the DataProvider.vb file will have a reference to lookup my custom provider instead of using the default provider.

It looks like there's a LOT more to change than just copying a folder and renaming some files if you want a custom provider to hit a different SQL database for membership management. Am I missing something? How do you get the SQLDataProvider.vb rolled into the custom provider if you don't alter it as a second project to be added to your solution (since it's not a part of the AspNetMembershipProvider vbproj)? How should the <data> section of web.config be addressed since that's the piece used to dynamically create the abstract object through DataProvider.vb?

Any insight is greatly appreciated!

Regards,
kwgainey

12/15/2006 12:18 PM

	Henry Kenuam
29 posts

Re: Building your own Membership Provider for DotNetNuke and ASP.NET 2.0

kwgainey

Just for clarification, the AspNetMembershipProvider reads and writes to two sets of tables, the local DNN tables (user, roles, etcc.) and ASPNET_* tables. This class forwards calls to .NET 2.0 Framework Membership classes to handle the reading and writing of data to the ASPNET_* tables. So for that part it doesn’t use any methods on SqlDataProvider directly. Internal to the AspNetMembershipProvider it also makes calls to internal methods to read/write data to the User table (DNN table this is who uses the dataprovider.Instance defined at the top of the class.). i.e. If you look through the call stack for AspNetMembershipProvider .CreateUser() it does both. Note: Look at the Imports at the top and you’ll see an alias: Imports AspNetSecurity = System.Web.Security

Your task is to replace the ASPNET_* tables with your own. The code to read/write to the local DNN tables should remain.

“However, SqlDataProvider.vb in the SqlDataProvider folder, as copied from the AspNetMembershipProvider folder isn't used or referenced in my new custom provider project. “

Correct. This is used by DNN and will be there as part of the site install. So you won’t need to modify that code.

If you choose to follow DNN”s model to make your own SqlDataprovider you can. This class would contain all “your” calls to your database to answer the questions that are required by your new AspNetMembershipProvider class. You could add your own section to the web.config however I would not. Your code is the only one that needs to know about the datastore. Instead just create a new entry under <ConnectStrings> for your server/database.

“It looks like there's a LOT more to change than just copying a folder and renaming some files if you want a custom provider to hit a different SQL database for membership management. Am I missing something? “

Yes, it’s no trivial task to implement your own provider. You must review/modify every method in your new version of AspNetMembershipProvider class. If you replace all calls to the MS Membership classes i.e. System.Web.Security.Membership.CreateUser() with your own. The end result is that you no longer have a dependecy on the ASPNET_* tables/objects.

Hope this help,

Henry Kenuam
Engage Software
St. Louis, MO
314.966.4000

The leading provider of DotNetNuke support, training and custom development.

12/28/2006 2:20 AM

	Chandu
2 posts

Re: Building your own Membership Provider for DotNetNuke and ASP.NET 2.0

Hi, Great article. Please help me i have following question.

I have an application developed in DNN 4.0.1. Now i need to develop a Custom Membership provider for this application. I followed your article and looked for the ASPNetMembership provider entry in web.config file to replace with my provider but there is no such entry in the web.config file. But i can find these entries in DNN 4.3.5.

Now how do i integrate my membership provider with DNN 4.0.1? What are the settings i need to do in web.config file? pls help.

Thanks

hkenuam wrote

I decided to create a document that would help developers get started building a new Membership Provider for DNN. If you are looking for a good place to get started this is the place

You can also download this information via this PDF file.

Overview

DotNetNuke uses the "Providers" pattern extensively in order for developers to change functionality without having to modify the Core code base. Using well known interfaces and/or abstract classes developers are able to "plug-in" new behavior for their implementation and ultimately can be used by custom module(s). For the core code executing against these classes, it is none the wiser as to the "how" or "where" the custom implementation is running or handling requests, if at all. DNN Membership and Role providers are examples of this pattern.

This document was developed using DotNetNuke 4.3.4, but should work for other versions of DotNetNuke 4.3.*

Intent

This document intent is to provide DNN developers a "starting point" source of information to replacing the out of the box ASPNetMembersShipProvder with a custom provider. Included are also some important considerations that will need to be made before you begin development and how you can get started programming your implementation.

Considerations

If you are considering replacing the Membership functionality you should ask yourself these questions:

Why am I replacing the membership (authentication) in the first place? The answer should be that I already have an existing data store with a user base and I want to validate user from my DNN site against.
Can I achieve what I need by adding on to the existing functionality provided or am I replacing the user's data store and the validation process entirely? In some cases, it may make more sense to sync the users and passwords into the default ASPNET tables. This could be desirable if the long term strategy is to phase out the other system entirely.
Does the other system that I plan on replacing provide enough functionality to satisfy the abstract MembershipProvider that DNN uses? Important! You must look through the list of methods/properties that this abstract class contains and be sure that you can provide answers to those questions as needed in order for your implementation to work seamlessly.
Can I retrieve a decrypted password from the new data store? It is important to understand how you will handle password resets, forgot password and random password generation before you start. Otherwise you will not be able to provide this functionality in your custom provider.

Understanding all the Pieces

Before you begin, it is very important to understand all the pieces within DNN. What are the membership and role providers? The first step is to locate the abstract classes (or concrete classes) that your implementation will be extending and examine all the signatures and their behavior. During this process you should be asking the question "how will my version answer these questions?". Below is an overview of the Membership and Roles implementation that should provide a good starting point for your project.

Membership

The membership provider provides the membership functions to allow a user access to your DNN site. i.e. Validating username/password. The default install for DNN uses ASPNetMembersShip provider. This provider class does not extend the Microsoft SqlMemberShipProvider class as with the previous versions of DNN. This is a very important difference. The ASPNetMembership class extends a DNN class DotNetNuke.Security.Membership.MembershipProvider which has a lot of the same signatures as the built in System.Web.Security.SqlMembershipProvider class. The ASPNetMembersShip class essentially forwards every request to the built in implementation from Microsoft to perform reads/writes to the ASPNET_* tables. The fundamental shift in thinking here is that DNN has implemented their own abstract class instead of programming against the System.Web.Security.SqlMembershipProvider (or MembershipProvider) class provided in the .NET Framework.

Roles

In some cases you may only need to authenticate your users via the primary data store. If your situation requires roles to be propagated to DNN you will need to make decisions about how roles correlate from the primary data store to the DNN role table. The RoleController and RoleInfo classes provide behavior for you to manage roles within DNN. In the simplest scenario, your DNN site will include a custom scheduled job to keep these in sync.

Interestingly enough, DNN uses the DNNRoleProvider class to provide role management locally and does not manage ASPNET Roles (aspnet_roles). Previous versions of DNN forwarded requests to the System.Web.Security.Roles.* methods in the same way that membership currently does.

Getting Started

What you need

You will need to download the source code for DotNetNuke 4.*
You will need to download and install the DNN Starter Kit on your development machine.
A blank SQL Server database named appropriately. This database will contain the DNN tables for your new site.

Configuring your DNN Environment

Download and install the DNN Starter Kit and install onto your computer. Start VS 2005 and select File à New Web Site. In the list you should see DotNetNuke Web Application Framework under My Templates. Select this option and provide a location/name for your web site. At this point the Starter Kit will create a default site for you and add references to your project (web site) to all required components. You should see a Quick Installation page that has some instructions about pointing to a database and how to configure. You will need a blank database specified in the web.config file the first time you run the site in order to install DNN and all related tables. Once you have created/configured the database go to the property pages for the site and look through the references for DotNetNuke.Providers.AspNetProvider. This reference is the reference that you will need remove and re-add as a project reference.

Now you need to locate the source code for DotNetNuke.Providers.AspNetProvider. This is located in Source\Library\Providers\MembershipProviders\AspNetMembershipProvider. It is a good idea to use this project code base as a starting point for your new MemberShipProvider. Make a folder (not under the web site) with the appropriate name i.e. EngageMembershipProvider and copy all the files into this folder. Next go to your web site references and remove the DotNetNuke.Providers.AspNetProvider reference. This step disconnects you from the default install for membership. Now add the project to your solution. Lastly, add a reference from your web site to your new MembershipProvider project. Note: This is a good time to change the name of the project, AspNetMembershipProvider.vb and so on. Once you have cleaned up the names of the project, class files and the output file name (????.dll) add the reference to your project.

Now, in order for DNN to load your Membership Provider you will need to update the web.config file. Scroll down to find the section of the file. You will need to update the path and assembly name to your new name.

Within your website your may notice there is a setting for DNN that tells the install whether or not to install the Membership tables.

The logic here is that you are replacing the default membership provider with a custom implementation that is pointing to totally different database/tables so why should I need the membership tables installed?

Do not change this setting if you are creating a brand new site/install. An existing bug with DNN attempts to read values from the aspnet_SchemaVersions table using the aspnet_CheckSchemaVersion stored procedure and will cause your install to fail. Until this issue is resolved with DNN you will have to either a) leave the membership tables, procedures and views in your database which is messy or b) selectively remove all database objects (except the two mentioned above) from your database afterwards.

At this point you should be able to run your application, if this is the first time the DNN install will begin and afterwards you can access your default DNN web site. You are setup with your new provider in Debug mode and can begin reviewing the methods on the AspNetMembershipProvider (or whatever you renamed it to) and begin thinking about how to replace the behavior to work against whatever data source you would like.

Conclusion

As you go through the steps of creating your own provider you may notice some things about the DNN implementation that contradicts the idea of a "Provider". With DNN's current implementation you cannot escape the local DNN tables. This is also true for the roles (and probably profile as well). In the end, this means that you will be creating/validating/managing users in two databases. You will need to make decisions about which attributes you will need to keep in sync (if any) i.e. email, name.

This version of Membership is greatly improved from previous versions and paves the way for developers to provide their own implementations running against existing data stores. This is a powerful sell point for DNN and allows enterprise level modules to be developed without expensive data migration and provides a consistent login for users.

About Henry Kenuam

Henry Kenuam is a co-founder of Engage Software and Chief Technology Officer. His responsibilities include overseeing the technical direction of the company. Henry ensures that the technologies used in software development efforts are proven and that the system designs are of the highest quality. He has over 13 years of Information Technology experience in Software Development and Design. Previously, Henry has managed multi-million dollar software development projects for Maritz. On the largest, a custom CRM (Customer Relationship Management) system for Toyota/Lexus (1-800-GOTOYOTA), Henry served as System Architect and Project Manager.

You can also download this information via this PDF file.

12/28/2006 9:14 AM

	Henry Kenuam
29 posts

Re: Building your own Membership Provider for DotNetNuke and ASP.NET 2.0

Chandu,

If I remember correctly, the older versions of DNN didn't allow you to plug in a new membership provider, or at least not as easy as it is in the later versions. Is it possible to upgrade your site to 4.3.x?

regards,

Henry Kenuam
Engage Software
St. Louis, MO
314.966.4000

The leading provider of DotNetNuke support, training and custom development.

12/28/2006 10:39 PM

	Chandu
2 posts

Re: Building your own Membership Provider for DotNetNuke and ASP.NET 2.0

hk,

I am not sure, if the client is willing to upgrade the site to 4.3.x but i can keep this as last option. You say that plugging in the membership in older versions is not as easy as it is in the later versions, which means it is possible with some level of difficulty. Can you please help me in acheiving this? Give me some clues like where to start, so that i can continue.

regards,

Chandu

1/2/2007 2:00 PM

	Chris Hammond
1117 posts

Re: Building your own Membership Provider for DotNetNuke and ASP.NET 2.0

Chandu wrote

Can you please help me in acheiving this? Give me some clues like where to start, so that i can continue.

The best place to start, honestly, will be to upgrade DotNetNuke to either the 4.3.7 release, or the 4.4 release and begin working with it. If you start developing a custom membership provider for a version that is not current, if you ever decide to upgrade to a more recent version of DNN, such as 4.3.7 or 4.4, or even a future release, you will most likely have to completely redo everything you're talking about doing now.

All in my humble opinion of course.

Chris Hammond

Directory of Training Programs, DotNetNuke Corporation

2/23/2007 8:39 AM

	Kevin
1 posts

Re: Building your own Membership Provider for DotNetNuke and ASP.NET 2.0

Great article... I created a custom membership provider. I am able to authenicate my user but I get an authorization error when I browse a page for "registered users". My issue is outlined on the DNN Forums...

http://www.dotnetnuke.com/Community/ForumsDotNetNuke/tabid/795/forumid/111
/threadid/110159/scope/posts/Default.aspx

Any help would be appreciated.

5/21/2007 9:18 AM

	roger
8 posts

Re: Building your own Membership Provider for DotNetNuke and ASP.NET 2.0

hi hk:

I should create a new membership provider to authenticate the user' information through an external database, which is created by myself. the final goal would be that i can manapulate the data based on my own database rather than aspnet*_ table. according to your article, I already built a asp.net web application project(IV_Portal MembershipProvider) in the same solution with dnn website. there are some default folder when i initialize the project. such as property, reference , default.ascx and web.config. following to your guideline, i remove the reference to DotnetNuke.provider.aspnetprovider.dll and add reference to the project i create in the asp.net web application format(IV_Portal MembershipProvider) in the bin folder belonging to dnn website. then, i add the two references(dotnetnuke.dll and dotnetnuke .membership.dataprovider.dll) in the reference folder of my own project. in the web.config file of website, i also replace the default member defination to"

<members defaultProvider="IV_PortalMembershipProvider">
   <providers>
    <clear/>
    <add name="IV_PortalMembershipProvider" type="IV_PortalMembershipProvider.IV_PortalMembershipProvider, IV_PortalMembershipProvider.Provider.IV_PortalMembershipProvider" providerPath="~\Providers\MembershipProviders\IV_PortalMembershipProvider\"/>
   </providers>
  </members>"

i adjust the data from my own database is through the objectdatasource, within which i use the dataset to create few data table like " users", "roles", "Module" and "group" , then i use tableadapter to create the basic methods like "add user" ,"del use" or "updateb user" . after all these things, i also built a folder to act as BLL which links DAL and API when implementing my project in dnn frame. but i found the errors appear when i initialize my project.

i think , maybe the problem should exist in the aspnetmemberprovider folder, i just copy the exactly same files in the folder to my own folder named IV_portalmembershipprovider. nothing changed for all of those. can you tell me should i change something and how can i change it to adapt my current situation?

thanks a lot for your help!!!

roger

Page 2 of 5

...5

Support Forum

DNN General Dis...

Membership Prov...

Building your own Membership Provider for DotNetNuke and ASP.NET 2.0

Purchase

Please click here to buy now.
Payment will be processed via credit card or PayPal.

Test Drive!

Want to find out how it works? Visit our demo site to see the modules in actions!

Online Support

Documentation
Support Forums
Tutorials
Wiki

Documentation
Support Forums
Tutorials
Wiki

Forums

Overview

Intent

Considerations

Understanding all the Pieces

Membership

Roles

Getting Started

What you need

Configuring your DNN Environment

Conclusion

About Henry Kenuam

Purchase

Test Drive!

Subscribe

Online Support

Mailing Address

Contact Info