Настраиваемая авторизация в Asp.Net MVC

По-моему, адский велосипед. Еще и в области безопасности, где за каждый баг (а у вашей реализации, я уверен, их больше, чем у стандартной) могут что-нибудь оторвать. ИМХО, реализация (Extended)MembershipProvider для нужд конкретного домена будет гораздо проще.

Особо внимательно код не смотрел, так что извините, если упустил какую-то критически важную деталь.

А Windows Identity Foundation чем не устроил?

Password Authentication — а где можно почитать про этот провайдер? Или имелось ввиду Passport Authentication?

Вообще всегда реализовывал MembershipProvider с перегрузками, никогда никаких особых порблем не испытывал. Вполне себе проверенный практикой и секьюрный метод аутендификации. Писать свой способо с нуля требует времени и вероятность получить дырявый порвайдер. Зачем на это тратить время, если есть проверенные вещи?

Соглашусь с tp7: Адский велосипед :)

Во-первый, вы реализовали ACL based security на базе Role Based Security — гремучая смесь.
Для ACL based security уже давно существует WIF (Windows Identity Foundation)

Во-вторых, вы спутали аутентификацию и авторизацию — это всё-таки разные вещи.

public interface IIdentity
{
    string AuthenticationType { get; }
    bool IsAuthenticated { get; }
    string Name { get; }
}

IIdentity отвечает на вопрос: Кто ты такой и как тебя зовут

А вот:

public interface IPrincipal
{
   bool IsInRole(string role);
   IIdentity Identity { get; }
}

отвечает на вопрос: Чем мы владеем, т.е. какие роли у нас существуют.

Другими словами, ваш IRule — это ClaimsAuthorizationManager

public interface IAuthorizeService<in TAccount>
{
        void SignIn(TAccount account, bool createPersistentCookie);
        void SignOut();
}

И так, SignIn & SignOut — это методы аутентификации, но уж точно не авторизации, как я сказала выше.

Теперь, если мы перейдём к Windows Identity Foundation, то мы откроем для себя много интересного:
1. Пользователь может иметь больше чем один способ аутентификации, в реальности, это может быть аутентификация в нашей системе + ещё всякие там токены от соц. сетей или ещё от чего-то там

2. Зачастую аутентифицированый субъёкт хочет аутентифицироваться ещё где-то, т.е. провести процедуру ActAs и для этого ему нужен будет bootstrap token

3. и так далее

Это я к тому, что вы потратили время на написание фабрики по выпуску абстратных фабрик, к тому же наследие в вашей реализации — всё сильно усложняет, и практически не даст вам возможности изменить систему аутентификации и авторизации.

Фактически, всё что вы тут нагородили, сводится к тому, что для доступа к ресурсам вам нужно проверять наличие тех или иных аттрибутов у аутентифицированого субъёкта.

Для этого достаточно было привести это всё дело к виду: Один ресурс — один аттрибут (claim), с правами read/write/delete или ещё что вам там нужно.

Implement custom Claim based Authorization in ASP.NET MVC Web Application

Я просто частично процитиру:

Authorization

The first thing to identify is to what types of claims make sense for our fictitioushospital.com website. Lets think of claims as permissions that are required to access the features. If we consider patients as resources we may have (CRUD) permissions like Patient Create, Patient View, Patient Edit and Patient Delete. So the possible list of claims may be:

1. Patient Create

Right: schemas.xmlsoap.org/ws/2005/05/identity/right/possessproperty
Claim Type: schemas.fictitioushospital.com/2010/02/identity/claims/create
Resources: schemas.fictitioushospital.com/2010/02/identity/resources/patients

2. Patient View

Right: schemas.xmlsoap.org/ws/2005/05/identity/right/possessproperty
Claim Type: schemas.fictitioushospital.com/2010/02/identity/claims/read
Resources: schemas.fictitioushospital.com/2010/02/identity/resources/patients

3. Patient Edit

Right: schemas.xmlsoap.org/ws/2005/05/identity/right/possessproperty
Claim Type: schemas.fictitioushospital.com/2010/02/identity/claims/update
Resources: schemas.fictitioushospital.com/2010/02/identity/resources/patients

4. Patient Delete

Right: schemas.xmlsoap.org/ws/2005/05/identity/right/possessproperty
Claim Type: schemas.fictitioushospital.com/2010/02/identity/claims/delete
Resources: schemas.fictitioushospital.com/2010/02/identity/resources/patients

И в завершение:
How To: Build Claims-Aware ASP.NET MVC Web Application Using WIF

Вы про константы не слышали?

Слышал)
Ну есть же вероятность, что такой как я «иноватор» не слышал.

А ad+anonymous не настраивали?? Очень острый вопрос. Гугл дает больше вопросов чем ответов.

Хм. Что мешает слить исходники mvc4, доступные открыто, посмотреть на то, как у них это все реализовано и не городить вот такое самостоятельно?
В исходниках, кстати много очень интересного.
Но по авторизации я далеко не лез, только немного подправил нужные мне методы — опять же, при обновлении версии mvc переносимость будет лучше.