Microsoft released a back port of the Whidbey membership api that is available here. I dug into this with great anticipation for an upcoming project and really thought it would be just the ticket for my upcoming web application needs. I had a number of reasons to be optimistic. I had dinner with Scott Guthrie “way back” at the 2003 PDC and talked about this api and sat through his presentations at PDC. After some followup email, I determined that some of the missing features, such as account lockout would be part of the api. I have used a derivative of the original IBuySpy since our early release and though the Forms Authentication apis were a pretty good start, I assumed that the new code would be an incremental improvement over that original base.
Well I was partly correct. The api and those sorts of things you should always think about when doing web security are well represented in the interfaces and the provided SqlMembershipXXXX classes. Account lockouts, user information, a flexible state collection of attributes, roles, login, user online features and much more are present. Good, that is what I expected. What’s really new is that all of these things are provided to the execution context automatically by configuration, where in the past you had to wire up these things, much of it on your own, in Global or some suitable alternative. The design does seem to correctly abstract a lot of this stuff out and make it easier to plug in just what’s unique to your application.
Hopefully I have thrown enough positives to keep you reading through the rest, because in the end, I am not sure how I can use this at all. The problem, at least as it stands with the current back ported code drop and all it’s associated disclaimers about future api changes, the problem is that nasty “let me configure a static instance for you” type of solution that so often just doesn’t work. DAAB for example which has now been largely rewritten is a good example. What’s the problem?
OK, in my world, I have many different types of authentication stores and I think most people are in a similar situation. So, I have user information in Active Directory for internal users. I have a contact system that contains user profile information about one class of customers. I have a variety of different databases containing user credential information that vary depending on many factors, but when they were developed is the most common one. Roles are another story. Roles are determined along a chain of decisions from different sources. Portal configuration, active directory groups, application configuration, application logic all have a place in determining roles for a user. The point is that many enterprises contain users in a wide variety of information stores each of which has it’s own nuances for connection, validating and retrieving identity information. And, you don’t know