Прошло 6 месяцев с тех пор, как вопрос был задан, и, похоже, никто не смог дать ответ, поэтому я решил объяснить решение, которое мы в итоге выбрали.
По сути, мы решили не использовать какую-либо реализацию MembershipProvider - вместо этого мы используем нашу собственную Службу членства, расположенную поверх хранилища. Для нас было важно сохранить существующую базу данных aspnet_Membership, чтобы наш репозиторий в основном дублировал встроенную функциональность SQLMembershipProvider (по крайней мере, те аспекты, которые нам нужны) - первоначально через Linq-to-SQL, но теперь мы переходим к NHibernate. , План состоит в том, чтобы заменить базу данных о членстве примерно через год, когда все наши веб-сайты будут обновлены для использования новой модели.
Можно было использовать настраиваемый поставщик членства, но в конце концов стало очевидно, что использовать настраиваемую реализацию проще, проще и удобнее в обслуживании. Мы по-прежнему используем встроенную функцию проверки подлинности с помощью форм для проверки того, что пользователь вошел в систему, и для перенаправления пользователей, которые пытаются получить доступ к защищенным областям нашего сайта без предварительной проверки подлинности, но мы переопределили функциональность, связанную с поставщиком профиля. .
В конечном счете, мы считаем, что, хотя поставщик членства является мощным и простым в использовании инструментом в ASP.Net, если он не соответствует более широкому подходу, используемому в вашем приложении, его стоит рассмотреть альтернативный подход.