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 ........