На двух стульях: ASP.NET Identity и авторизация по Windows в ASP.NET MVC

[mvv-rus]

Это все интересно. Но я не вижу в вашей статье, как у вас подключается авторизация к конкретным действиям конкретного класса контроллера. Предполагаю (ибо это логично), что заменой атрибута [Authorize] на [CustomAuthorize] с теми же параметрами конструктора атрибута (или без них) для контроллеров и их методов действий. Но лучше про это (или про реально использованный альтернативый вариант авторизации подключения — такие тоже есть, помню, минимум, один, но ЕМНИП их больше) было бы написать в статье.
А ещё я бы попробовал использовать в качестве хранилища ролей саму Windows — в качестве ролей там выступают имена групп, в которые входит пользователь. Для этого в раздел <system.web> надо включить элемент

    <roleManager defaultProvider="WindowsProvider"
      enabled="true"
      cacheRolesInCookie="false">
      <providers>
        <add
          name="WindowsProvider"
          type="System.Web.Security.WindowsTokenRoleProvider" />
      </providers>
    </roleManager>

Имена ролей при этом будут иметь вид имя_домена\имя_группы (или вид имя_компьютера\имя_группы для локальных групп). Плюсами является то, не надо мучить EF — список груп пользователя приписывается ему при аутентификации Windows, что в Authorize надо поменять имена ролей (или дописывать к ним имя компьютера/домена в CustomAuthorizeAttribute), и что если сервер находится в домене, то можно, скорее всего, использовать доменную аутентификацию (IE это точно умеет, Chrome AFAIK тоже, насчет FF не скажу совсем), т.е. пользователями из домена, скорее всего, вообще не нужно будет вводить логин/пароль.
Правда, в вашем тексте нет ничего про таблицу Procedures и связку ролей с ней, и если это играет какую-то роль в авторизации пользователя (я эту роль не понял), то через членство в группах Windows в качестве ролей ее использовать будет, наверное, не сильно удобно.

[NewTechAudit]

Добрый день!

Насчет использования новых классов – да, они были использованы в качестве замены [Authorize].

Касательно описания примеров использования – изначально я, когда готовил статью, думал, что описания «на словах» будет достаточно, но по прошествии некоторого времени всё-таким соглашусь, лучше было бы описать их кодом. Спасибо за замечание, исправлюсь :)

Относительно использования WindowsTokenRoleProvider – изначально мы его и хотели использовать при доработке механизма авторизации, и на мой взгляд, решение более правильное, но:

1.       Мы столкнулись с тем, что существующие группы никак не позволяют одной или несколькими охватить перечень пользователей, которым мы бы хотели давать доступ к ресурсу.

2.       Список групп никто не стал бы редактировать под нужды одного нашего ресурса.

Список пользователей с доступом к ресурсу постоянно меняется – скорее всего при этих обстоятельствах пришлось бы хардкодом прописывать пользователей, а не описать красиво <<DOMAIN>>\\<<GROUP>>. Поэтому мы и приняли решение оставить EF, и подтянуть к нему УЗ Windows, чего мы, в принципе, и достигли.

По поводу таблицы Procedures – это отдельная история. Вкратце, на схеме в статье есть две таблицы с ролями:

1.       AspNetRoles (к ней цепляется EF и [Authorize] и через неё в принципе регулируется доступ к ресурсу и админке)

2.       Roles (группы пользователей внутри ресурса, через которые регулируется доступ к выполняемым отчетам и процедурам).

Две таблицы с ролями – это конечно сильно, но это дает нам легко настраиваемую ролевую модель, которой нам не хватает в группах. Хотя, мы уже потихоньку думаем над тем, как понятно отрефакторить их так, чтобы получить вместо двух таблиц одну.