One feature of ASP.NET configuration files and the new configuration files for IIS 7.0 is an attribute known as configSource.  For the elements that support this you will have a few different options for dealing with configuration.  This value in this attribute can point to any file path that is lower in hierarchy, but may not be higher or on a different disk.

With this feature you can manage configuration sections in separate files.  Also, in IIS 7.0 you can include another attribute to flag the configuration not to cause an application restart when the configSource file changes.  Perhaps that will be in ASP.NET 2.0, but I have not discovered it yet.  By default it will cause a restart of the application just as web.config changes do.

For those of you who are following the back ported Membership API I have some news.  Tonight I had opportunity to visit with Scott Guthrie and I asked him when we might see the download return.  He indicated that it was likely not to return.  Currently DotNetNuke and Community Server are both licensed to use it.  Others can request it and will likely be granted license, but the issues around supporting it are apparently causing Microsoft to hold back on releasing it openly.  For those wanting to check it out you probably should plan on following the steps I outlined when it first appeared.  I will leave the latest changes in implementation to you for now.  Those who really want it will need to find a way to request it from the ASP.NET team.

Scott Guthrie, here is a thought.  Perhaps you could give it to a 3rd party like myself or someone else who could maintain it in an open source model.  That would free Microsoft from supporting it and still allow the community to begin writing against it to prepare for .NET 2.0 and gain its advantages today.  I would be happy to rebuild it under a new namespace to remove Microsoft from responsibility for support and updates.

A couple other news items from Scott.  Sharepoint 2006 or whatever the next version is called will support forms authentication for Internet sites.  He has updated his VirtualPathProvider sample code for Beta 2 of VS 2005.  See the download for the March 20, 2005 talk from VS Connections in Orlando.

I have had some readers tell me that my link to Microsoft's back-ported membership API is not working.  I am aware of that.  Apparently it has been pulled so that it can be brought into sync with Beta 2.  There have been a few database changes for the SQL providers and some minor API changes.  I hope we see it back online soon, but I have no idea when it will show up again.  In the meantime you can still get it the hard way.

Permission Manager has been updated for Beta 2 of VS 2005.  The more exciting part is the addition of Authorization Manager.  This is similar to the AzMan from Microsoft in purpose.  The best part about Fredrik's version however is that it is true .NET and does not require any install (think standard .NET XCopy) or COM+ registration like AzMan.  For more info head on over to the run down on Fredrik's blog.

After lunch yesterday I continued the session on OO with Rocky.  I really appreciated the practical aspects of his presentation.  It is obvious he has been striving for OO purity and landing in the real world.  That is a difficult thing to do, but so often necessary.

Fro example he said that Tiers are bad.  He was speaking of physical ties in the architecture.  The obvious problem with Tiers include the deployment issues and performance issues.  The trade offs include scalability, fault tolerance and security.  At Idaho Commerce and Labor those of us doing more Object centric development have realized how painful it is that we are running on a web farm.  If the user sessions were sticky or we we running on a single front end box then we could use caching and working with object graphs would be smother.  So, I definitely understand and agree with Rocky that Tiers are bad.  I have also come to believe that many solutions would be best run on a simplified physical architecture.  So often more energy and money is put into redundancy than it would cost to have a hot spare standing by with instructions for staff on how to switch it over.  Of course there is no perfect one size fits all solution.

Another thing that struck me was Rocky's belief that using serialization is bad practice for persistence.  To clarify he was not talking about an in memory working set, but for long term storage.  Serialization is necessary for passing objects around, but has significant challenges when it is used as a more permanent storage mechanism.  The biggest problem is versioning.  Say you store an object and then have a need to modify the class by adding or removing properties.  Then you try to deserialize your stored object for version 1 of the class using the schema of version 2 of that same class.  OOps!  There are ways to deal with the versioning issues, but Rocky's opinion is that its not worth it.

I was impressed with the CSLA Data Portal concepts as they are similar to many of the ideas I have been considering in the past.  Primarily I like the concept of a single port of entry for storing and retrieving objects. 

My conclusion is that I want to use the CSLA framework.  It has been well tested in the real world.  Well improved since the book was printed.  Actively used in the community.  Strives for purity, and lands in reality. 

Only 1 major complaint I have and I need more experience to decide where to land.  Love to have feedback from others on this.  In the CSLA framework the Data Access methods are contained within the Business Object Classes themselves.  The pattern I prefer places the Data Access in its own classes.  I like to have a Manager class or service class has responsibility for persistence.  I asked Rocky about it and he is happy with his solution of course.   The reason is private members.  The only way to persist and retrieve private members is if you have access to them which means you are either inside the class or you are using reflection.  Reflection is expensive and much more difficult.  As I think about the purpose of private fields I realize that they certainly can and do exist without a public property accessor.  Also, the encapsulation of of property into a private field allows for some behavior in the Get/Set blocks.  Often you would not want that behavior to happen if you are merely recreating an object from a data store.  If the Object itself represented data and not behavior then it be much less of an issue.  Of course understanding Rocky's presentation that objects should model behavior and not data helps me to clearly understand his framework decisions.

Take a look at the ASP.NET 2.0 Membership system.  It uses the static Membership class for persistence and creation of MembershipUser.  This doesn't fit Rocky's model because the business object of Membership user is not responsible for its own persistence.  I like it much better though because the behavior of persistence is modeled separately than the behaviors around the authentication object. 

Anyone care to share their thoughts on this?  Is it a case or purity meets reality?  Perhaps some Objects best fit the CSLA model and others a different model?

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.

A few months back I was talking with some other developers on the v.Next project about how we could abstract security out of our code.  The desire was to have methods and code blocks that could be wrapped with security checks, but without hard coding user or role names.  The current IBuySpy and Rainbow Portal for example have code in them like this if (User.IsInRole("Editor")) {do stuff}.  That works fine for a simple application, but what happens when you want to allow Admins and Editors?  In today's model you end up modifying the code and re-compiling and deploying.  I have seen a lot of code that strings together a bunch of OR statements when additional Roles need to be supported for a given security check.  It can get very ugly.

The solution is to have the authorization and permissions abstracted from the application so that when Users and Roles change you can easily change the security inside the application without changing code.  Enter Permission Manager (PM).  PM is the coolest piece of code I have seen for Whidbey so far.  I really can't believe something this good is already available and Whidbey just hit Beta 1.  It could be that I was already talking about building something like this that makes it cool, but for me it is how nicely it fits the ASP.NET 2.0 experience.  The code looks like it is native to ASP.NET.  It seems to follow the style of Microsoft's built-in classes very nicely.  It plugs in beautifully to the provider model allowing you to use it with your own custom provider for managing the permission sets for an application.

PM works by allowing the developer to create an abstracted permission object that implements IAccessObject.  This is simple to implement with basic name and ID properties.  The object then is used with the PermissionManager to create named permissions.  The sample has a news object that is used to create various permissions.  These permissions are completely separate from Users and Roles until you map them together.  For example, within the news permission set we may want a print and copy permission.  Using the PermissionManager static methods we make simple calls like: PermissionManager.CreatePermission(news.SourceGroup, "Copy", "Copy a document"); to create the Copy Permission.  When we want to map a real Role to the Copy permission of the news object we simply execute a method like this: PermissionManager.SetPermissionForRole("Copypeople", news, "Copy");.  This maps the Role of Copypeople to the permission of Copy on the news object.  news really is just an object for grouping of permissions.  Each application could have its own set or several sets.  Through the provider model permission sets could also be shared across applications by pointing them at the same data source.  This abstraction model allows us as developers to have as many application permissions as we want without needing matching security roles for each one of them.

This abstraction of Permissions is something that applications like Rainbow portal did with a lot of database mapping.  The problem has been that some Roles are hard coded and there is not a consistent provider based system for managing permissions.  I plan to give this concept a thorough workout as I start working with Whidbey.  It could also be ported to ASP.NET 1.x if you had a Users and Roles store that you could tie it in with.

One of the features of .NET 2.0 that I am excited about is the provider design pattern (This site is active but empty.  I plan to document as much as I can about providers on it as a way to help the community).  I decided that today I would begin looking at what it will take to use this in the applications we build at Idaho Commerce and Labor.  We plan to take advantage of this model as a way to share users, sessions, navigation and more across applications.  We need to investigate the security issues related to this of course.

So far I have discovered that the SQL providers can be installed with a utility called aspnet_regsql.exe in the %windir%\Microsoft.NET\Framework\v2.0.40607 folder.  I called my database Credentials since I was planning on working with Membership.  Now that is is created I see that it installs all of the SQL providers.

The tables I understand: Membership, Personalization, Profile, Roles, Site Counters, Users, UsersInRoles

There are other tables in the database as well that I assume are for some management and other purposes.  These include Applications, Paths, and WebEvent_Events.

What I do not see here is Sessions and Navigation.  I imagine that like .NET 1.x SQL Session state is a separate script to run.  More on that when I get to exploring the Session State provider.  As far as providers for navigation, I imagine that will be something custom I get to build.

I am now curious to see how this default SQL provider and its database will work when I point multiple applications at at.  What can and can't be shared.  Then I have to ask what should and should not be shared?

First of all, I must say that sitting on the end of a 3MB cable Internet connection is fabulous.  I was able to download all of the VS 2005 Beta Cd's, 2005 MSDN library and the Express product betas in a few hours.  I wanted to start playing with them before the DVD's are mailed out (could be 2 weeks) so I went ahead and grabbed them from MSDN.

The Express products can be downloaded by anyone and I initially downloaded them from the public site.  I was disappointed during the installations when I had only a setup and it had to go retrieve the full product with another download.  I must have missed that note somewhere.  With VB.NET and C# the download was not bad since they are under 30 meg, but with VWD (Visual Web Developer) the download was something like 186 meg.  If you have MSDN you might want to skip this by just grabbing the full ISO images.  Again, very nice to have a fast connection to the net!

I decided to put the 3 Express products I might use (VB, C#, VWD) as well as SQL Express all on a single VPC image.  That will allow me to play with them but not have to manage too many extra playgrounds.  The installation for all 4 products was smooth and I am looking forward to giving them each a test drive soon.

VS 2005 Beta 1 surprised me with its install.  I first tried it using the Windows XP Virtual CD-ROM tool, but I got an error on the first CD ISO image.  I am not sure why, but after making real CD's to install from everything went great.  I do not remember how long the install of VS 2003 took on my laptop, but I do believe 2005 Beta 1 was significantly faster.  I am installing on a VPC using a firewire drive for the image, but I would think that to be slower than the native OS and built-in IDE drive.  I will be curious to see what others think of the install time.  I am at about 2.5 hours right now and just got the reboot message.  This still isn't a coffee break install, but none of the VS.NET products have been.  The best part with VPC is that I can use the Undo feature and also share this image with co-workers saving them the install and setup time.  I wonder how long it will be before VPC images become the norm for beta products and all software testing?

For beta 1 so far I am very pleased!  Now it's time to start coding and see where the dev teams are still working on the feature set ........