When you need a Custom Membership provider

When I was in Cairo for the MDC a few weeks ago, I gave several talks that touched on the new membership controls in ASP.Net 2.0.  One question that came up repeatedly was how far can you stretch the provider before you have to write a custom membership provider.  The answer turns out to be not very far.  The provided membership providers are very good and very extensive, but they are also fairly rigid in their implementations. 

I think I have the 3 criteria that will force you to realize that you need to bite the bullet and write your own membership provider:

  1. If you need to access your own schema that is different (in any way) from the schema provided.  Running Aspnet_regsql.exe creates a database and if you need to edit that schema then you cannot live without a custom provider except if you are adding tables for your own use, but bear in mind that the provider will just ignore your additions.

  2. If you need to access data in someplace that is not supported.  Even if you want the same schema as the default providers support, you cannot use a proprietary database for that data and expect the providers to just work.  The XML provider is the most common example (though not very real world), but you could think of many scenarios including SQL 7.0 where a custom provider would be in order

  3. If you need / want to insert some abstraction between the provider and the data.  Stefan Schackow of Microsoft had a great session at PDC 2005 in which he demonstrated creating a provider that allowed for the situation where your web servers were not in direct contact with the database server.  To solve that problem he wrote a provider that took a web service endpoint as its connection string.

So as you can see you are quite likely to find yourself having to write your own provider.  The good news is that it really isn’t that hard to do once you have done it once or twice ;)

.Net 2.0 ClickOnce Security Concerns

Dominick Baier of DevelopMentor, wrote on Saturday about a pretty dramatic change in the way ClickOnce security is configured by default in the RTM version of .Net 2.0. 

This is a must read if you plan to use ClickOnce and haven’t already revamped the default security settings.  If you don’t like the ramifications that not being able to disable ClickOnce brings then rather than avoiding the .Net 2.0 offering you might consider the lesser step of just removing the .application mapping from your systems.

I am hopeful that Microsoft will come up with a fix in a service pack to .Net 2.0 as they did in the original .Net 1.1 that will address this default.

Suing over security

A recent court case was brought to my attention in which a user whose personal and financial information was stolen tried to sue the company for not using encryption on the data.  The article covering it is explains how the data was stolen and the ruling of the courts.

The question raised is whether the suit should have been supported?  While I agree with the ruling, I think that certain industries need to actually gradually design best practices like the use of encryption into their required security precautions.  This may be pandora’s box, but if it is done over time then it might actually be done right (wishful thinking?).

Security is still black art to most people.  We need to define “reasonable measures” in ways that make sense to the masses.