Just dont throw out the idea of an enterprise library based on authentication for a couple reasons. One, if you don't like the code exactly as is, you can change it! The other is that authentication strategy doesn't really have to do with the library, but with your own coding and data access standards.

We certainly haven't thrown out the idea.  We will just have to investigate how best to implement it in such a manner that we are satisfied with the approach and flexibilty it gives us. Just a note, we are currently using a modified version of the precursor Microsoft Application Data Blocks.  We did in fact end up "changing the code" in a # of different ways because it was lacking and we didn't like the things that it assumed.  Earlier versions of it did not have the built in flexibility that the Enteriprise library appears to now have.  This had me concerned that we were being herded down a path that we did not necessarily wish to go just because "everyone else is doing it".  But it sound like my concerns will be allievated.  Thanks for all the input.

Data Access is just part of the Enterprise Application block it comes with everything you need to create a .NET application and SA is not required but DBO is needed if your application will use stored procs.  This new version uses DataReader most of the time which uses sp_executesql in the background.  It will help if you get to know it better.  Try the links below for details and a new book is out but it was based on the older version.  Hope this helps.

http://www.gotdotnet.com/codegallery/codegallery.aspx?id=295a464a-6072-4e25-94e2-91be63527327

http://msdn.microsoft.com/msdnmag/issues/06/07/PatternsAndPractices/default.aspx