In my previous Microsoft.ScalableHosting post I described with some excitement the .NET 1.x Membership API found hidden inside of DotNetNuke 3.0.  My excitement is mostly about using the API outside of DNN.  There is also excitement about the possibility of DNN supporting alternate authentication stores through the provider model and the improved API.  Windows authentication is something missing from previous DNN that may work well now.  I have not yet tried it.

2 days ago a document describing Membership usage inside of DNN was posted.  The reading of that document prompted several thoughts which I will share here.

Why use Microsoft’s Membership API? 

One of the important things the API does for us is standardize how authentication is handled in ASP.NET.  With everyone cooking up their own solutions we constantly are learning a different authentication methodology and system with every application.  With standardization of the API we can now use front end tools like the Login controls in ASP.NET 2.0.  As long as developers stick with the base API’s, controls can be written against them and have high levels of assurance that they will work consistently.

Second, an equally important feature of Membership is the underlying provider model for implementation.  With a provider back-end developers are able to completely customize their data storage and data access as it related to Membership.  This design pattern also allows every application that uses the Membership API to share user accounts and roles when so desired.  How many times have we heard the complaints that ASP.NET Forums doesn’t use the same authentication system as DNN, Rainbow and IBS.  As these systems are updated to support the Membership API the only thing required to share authentication will be a configuration line in the web.config to point them all at the same provider.

DNN 3.0 Membership description falls short!

The reason for this whole post is to share my belief that DNN 3.0 falls short in its implementation of Membership or at least the description of such.  Throughout the DotNetNuke Membership document I was disturbed by the logic I discovered.  In the section DotNetNuke & Whidbey (Page 1) Shaun Walker says that DNN must avoid creating its own provider to simplify future migration.  This is absolutely backward and representative of other architecture decisions that continue to pain DNN.  DNN already has a robust solution for membership data.  Apparently there are business rule dependencies at the data level in some places (Page 7, UserRoles).  DNN is classic textbook example of an application that should create its own membership providers for use with the API.  By doing so other applications could share DNN’s user base easily and DNN would not be forced to make as many core changes.

On one hand I am glad to see that Satellite tables have been created in DNN to separate Membership data for DNN specific user/roles data.  On the other hand, the integration issues should have nothing to do with the underlying data storage and instead be addressed in the DNN API’s.  With a custom DNN Membership system both the Microsoft Membership API and the DNN specifics could easily be combined.  This would allow DNN to use any Membership provider while still supporting all of the DNN specifics and managing synchronization issues.  Page 9 CBO (Custom Business Objects) is exactly the right approach.  I believe the issues are being addressed, but the failure to see things from a Domain (objects, services) perspective really bothers me.  DNN thinking still tightly couples Data structures and the API’s and the 2 should be considered separately. 

Sharing users between portals is now a simple matter of sharing the ApplicationName that the Membership provider uses.  To make users unique all that is needed is to use unique ApplicationName’s.  The scenarios presented in Deployment Scenarios on Pages 1-2, Data on Page 3 and Multiple Portals on Page 10 do not make much sense.  By standardizing on the API, any deployment should be supported as long as a provider is used that supports the desired scenario.  The provider is the implementation and it is the key to supporting different scenarios.  Thankfully MembershipProvider.ApplicationName can be changed on each request enabling support for multiple portals with or without shared authentication systems.  By using multiple providers it is even possible to use different authentication stores for each portal in a DNN multiple portal scenario.

In Development Tasks (Page 2) it is apparent to me that there is a significant misunderstanding of Membership that must be clarified.  It is true that the UI controls built on top of Membership have not been back ported.  But there is a clear separation of the API and the SQL DB & Provider.  The API and the Provider should not be confused.  They must be considered as independent components.  Sure they work together, but the API does not in any way dictate underlying provider or storage that is used.  See the sidebar on the Membership API architecture at the end of this post.

When I hit the Data section at the end of page 2 and beginning of page 3 hope was returned to me.  Separation of responsibility is acknowledged between DNN data and the Membership data.  This is absolutely critical in order to use providers that only give DNN access to the data through the API and not in the database.  This separation creates a new paradigm for some developers.  It requires business rules to be placed in code and not in stored procedures.  The code has full access to the data through the API, but the database has no access to it or knowledge of it unless developers violate the intended usage.  If you are used to putting rules in your database it’s time to quit it!  You are asking for trouble with Membership data if you do this.  Thankfully DNN has fully acknowledged this in the Membership area.  Now we all need to be building software with the principles of separation of responsibility from the foundation.

Custom Attributes on Page 4 shows more confusion about the API and Provider.  It leads me again to believe futher that a DNN provider and custom DNN system would be best.  The custom attributes of course would still have to be treated as DNN specific data, but that is acceptable and exists no matter how Membership is implemented.  (DNN developers, I am not suggesting you replace Micrsoft's Membership, merely that you wrap it to support your additonal features.)

As a final note I want to publicly state that even though I have been critical of DNN here I am mostly seeing a reflection of my own failures in software development.  Now I desire to improve my own practices and help others see the benefits of good architecture and patterns as well.  With DNN’s prolific exposure it deserves a careful critique so that its best practices are adopted and its worst avoided.  This critique in no way reflects my opinions of Shaun Walker or any DNN developers.  Shaun and I have met personally and I enjoyed my meeting with him.  I also have great respect for him and his work in the ASP.NET community through the DNN portal.  Some readers may also know that I work with Rainbow Portal.  I choose not to be a fanatic about software and this post is neither for nor against DNN.  Each person must choose the solution that is best for them.

Sidebar: UserName and RoleName are not updatable through the Membership API as indicated in the DNN document.  The SQL database that goes with the default SQLMembershipProvider does not prevent you from updating UserName or RoleName through your own tools.  All relationships within the database are done by unique id’s so changing names will not break anything.  If you desire to change these names you must simply take care to update your own systems that may reference them and also to ensure that you keep them unique per application.  (Application referring to the definition of application inside of the SQL Membership database.)  Perhaps Microsoft should expose UserId and RoleId through the API so that we can store those in our applications instead of storing username and rolename as the unique ID’s provided through the API currently. 

Let me suggest a Membership best practice here.  Windows authentication uniquely identifies users as DOMAIN\USERNAME.  When using the Membership API with forms authentication I suggest always using APPLICATIONNAME\USERNAME.  By doing that you will be able to uniquely reference Membership users throughout your systems and not have to worry as much about username conflicts that could occur otherwise.

Sidebar: A look at the Membership API architecture reveals a nice model that may fit many other areas well.  MembershipUser is a simple entity to work with.  Its functionality is limited a single are of responsibility.  It knows nothing about the data store it is persisted in or even if it is persisted.  It also knows nothing about the collections it may be contained in (Roles).  To interact with an underlying storage system the Membership API acts as a service layer between the MembershipUser entity and a persistence Provider.  The Provider layer allows for complete control of the Membership implementation as it interacts with a persistence store.  The store may be a database, flat files, memory stream, or anything a developer chooses to be the implementation of the fields and methods required by the Membership system.  Developers are given a standard API to program against without concern for the underlying database.  The database designers do not have to be concerned with the API or the Domain entities that may represent the data.

using Microsoft.ScalableHosting;  // What is this namespace all about?  Read on!

With the release of DotNetNuke 3.04 in public beta comes a very interesting and powerful assembly.  A close look in the MemberRole.dll reveals that it is a fully functional port of the ASP.NET 2.0 Membership API.  So far it also looks to be a complete port.  The API includes features not even found in ASP.NET 2.0 Beta 1 such as account lockout.  This assembly contains several classes in the Microsoft.ScalableHosting namespace.  Classes inside this assembly include:

ProviderBase
Profile, Membership and Roles specific configuration classes
Profile + SqlProfileProvider
AnonymousIdentificationModule (httpModule)
Membership + SqlMembershipProvider
MembershipUser
Roles + SqlRoleProvider
RoleManagerModule (httpModule)

There are many additional classes as well.  I extracted the necessary configuration in web.config and put together a simple application to test the API.  I had no problem creating users and adding them to roles.  The API and SQL Providers worked perfectly with both Forms and Windows authentication.

Note: when using Windows authentication and adding a user to a Role a MembershipUser record is added to the database.  I am now wondering how the aspnet_Users and aspnet_UsersInRoles tables will get cleaned up when a Windows account is deleted.  This is currently necessary to create the GUID for the Windows account that is added to the aspnet_UsersInRoles table.  ASP.NET team comment please!

The license information for this assembly can be found at: DNN3\controls\MemberRole\Member Roles (Conf) (1101204) FINAL.doc.  Looks like this is some kind of Beta release of the API.

The SQL database installation script is found at: DNN3\Providers\DataProviders\SqlDataProvider\InstallRolesProfileMembership.sql  You will need to do a global replace of {databaseOwner} in the file with dbo. or other appropriate ownership for your scenario.

To use the API's in your own application you will need to do a few simple things.

1. Reference MemberRole.dll
2. Create the SQL database (or write your own custom providers)
3. Put the appropriate settings in web.config.  (sample web.config)

To create your own providers start a new class project, reference memberrole.dll, inherit the appropriate provider base class and override the abstract methods and properties (Microsoft.SecureHosting.ProfileProvider, Microsoft.SecureHosting.MembershipProvider, or Microsoft.SecureHosting.RoleProvider).  Then reference your new provider in the configuration.

You can of course leave out any configuration and providers details that you are not interested in using.  The RoleManagerModule must be added to the httpModules collection if you want to have the roles for a user added to the authentication cookie as is common practice in 1.x applications.

If you are interested in more details about the Provider Design Pattern I plan to post addtional information and providers at www.aspnetproviders.com.

Now that I have the MembershipUser and Roles I am planning to port PermissionManager to .NET 1.x as well.  Together with Membership the PermissionManager completes authentication and authorization package allowing us to abstract all aspects of security management out of applications.

How will you make use of Membership, Roles, and Profile for your current applications?

My friend Fredrik Normen is at it again.  Permission Manager continues to improve.  Perhaps we should take it even further?

The latest enhancements give us the ability to specify permissions in the config file as well as other provider defined locations. 

 What does everyone think about putting this kind of configuration in an PermissionManager.config file or something like that as an option?  I imagine the web.config might like this: 

<permissionManager enabled="true" path="PermissionManager.config" />

As you can see all the remaining details might be found in an external config.  It seems with all the provider stuff the web.config is growing to be a very large file.  Of course we would want to still be able to use the Configuration API's as much as possible.

Thoughts on configuration and web.config usage?

For Permission Manager what about defining permissions in a custom attribute class and then having a reflection provider that harvests them from the assemblies during initialization.  My thinking is that we have a synchronization issue between the permissions defined in application and those defined in the provider store.  By using attributes and reflection the definitions in the code would always be in sync.  It would not be necessary to define the permissions in any external location.

Today we might define a Permission to secure a method like this:

public void foo () {
// Check Permission
if (!(PermissionManager.HasPermission(“Group“, "Permission", user))) {return false};
// Permission granted
// do stuff
} 

For this to work we also must make sure that the “Group“ and “Permission“ exist in the permission definition store.  This requires us to create the definition prior to executing a .HasPermission().

With attributes we could perhaps do this instead:

 // Check Permission automatically for current user? and define permission declaratively
[Permission(Group="Name", Permission="Name", Description="Description")]
public void foo () {
// do stuff
} 

Now with reflection we can harvest the necessary permission definitions right out of the assembly.  Any assembly that has a dependency on Permission Manager self describes the permissions it uses and checks attributes.  I still need to understand the details and possibilities around this, but it seems there must be a way to use attributes to define the permission and secure fields, methods, and classes.  The Conditional(”DEBUG”) attribute seems similar in concept.  Permission Manager defines a condition based on runtime security instead of compile time.  Those who have worked with attributes more please comment as to the feasibility here for both definition of permissions and runtime authorization checks.