I can't seem to get my head around how to implement a custom membership provider with Entity Framework data contexts into my asp.net MVC application. I understand how to create a custom membership/role provider by itself (using this as a reference).

Here's my current setup:

As of now I have a repository factory interface that allows different repository factories to be created (right now I only have a factory for EF repositories and and in memory repositories). The repository factory looks like this:

public class EFRepositoryFactory : IRepositoryFactory
{
    private EntitiesContainer _entitiesContext;

    /// <summary>
    /// Constructor that generates the necessary object contexts
    /// </summary>
    public EFRepositoryFactory()
    {
        _entitiesContext = new EntitiesContainer();
    }

    /// <summary>
    /// Generates a new entity framework repository for the specified entity type
    /// </summary>
    /// <typeparam name="T">Type of entity to generate a repository for </typeparam>
    /// <returns>Returns an EFRepository</returns>
    public IRepository<T> GenerateRepository<T>() where T : class
    {
        return new EFRepository<T>(_entitiesContext);
    }
}

Controllers are passed an EF repository factory via castle Windsor. The controller then creates all the service/business layer objects it requires and passes in the repository factory into it. This means that all service objects are using the same EF data contexts and I do not have to worry about objects being used in more than one data context (which of course is not allowed and causes an exception).

As of right now I am trying to decide how to generate my user and authorization service layers, and have run against a design roadblock. The User/Authization service will be a central class that handles the logic for logging in, changing user details, managing roles and determining what users have access to what.

The problem is, using the current methodology the asp.net mvc controllers will initialize it's own EF repository factory via Windsor and the asp.net membership/role provider will have to initialize it's own EF repository factory. This means that each part of the site will then have it's own data context. This seems to mean that if asp.net authenticates a user, that user's object will be in the membership provider's data context and thus if I try to retrieve that user object in the service layer (say to change the user's name) I will get a duplication exception.

I thought of making the repository factory class a singleton, but I don't see a way for that to work with castle Windsor.

How do other people handle asp.net custom providers in a MVC (or any n-tier) architecture without having object duplication issues?