Custom Membership Provider and Domain-Driven-Design

I have a concern where I am writing a custom membership provider, but I'm not sure where to put it. I don't really have any code to show you, but basically the provider needs access to System.Web.Security in order to inherit the class, but it also needs data access (i.e. a connection string + LINQ to SQL) to do simple tasks such as ValidateUser.

How can I write a membership provider that adheres to the principles of DDD that I've read about in Pro ASP.NET MVC2 Framework by Apress? My one thought was to write another class in my domain project which does all the "work" related to database stuff. In essence I would have double the number of methods. Also, can this work with dependency injection (IoC)?

Hope this isn't too general ...

Look forward to the hive-mind's responses!

Edit: I just noticed in a default MVC2 project there is an AccountController which has a wrapper around an IMembershipService. Is this where my开发者_如何转开发 answer lies? The AccountController seems to have no database access component to it.

Asp.net user management features are super invasive.
They even spam database with profile tables and what not.

When I had to implement users management of my application, I successfully avoided all that mess and still was able to use asp.net in-built roles, user identities etc. Moving away from all that though cause my domain is getting smart enough to decide what can be seen and done so it makes no sense to duplicate that in UI client.

So... yeah. Still have zero problems with this approach. Haven't changed anything for ~4 months.
Works like a charm.