Авторизация и роли в IIS 8

ASP.NET --- Безопасность в ASP.NET --- Авторизация и роли в IIS 8

Веб-сервер IIS 8 изначально поддерживает те же механизмы авторизации на основе URL, что и ASP.NET. С одной стороны, IIS 8 поставляется с собственным модулем UrlAuthorizationModule. Это позволяет настроить URL-авторизацию внутри опции <authorization> раздела <system.webServer> в конфигурационном файле web.config. С другой стороны, при запуске IIS в интегрированном режиме ASP.NET можно также настраивать веб-приложения, развернутые в IIS 8, на использование напрямую модулей URL-авторизации ASP.NET. Таким образом, можно полагаться на существующие конфигурации <authorization> внутри раздела <system.web>.

IIS 8 позволяет управлять правилами доступа к собственному модулю авторизации для веб-сайтов непосредственно в консоли управления. Вдобавок прямо из этой консоли можно также управлять ролями, находящимися в хранилище данных сконфигурированного поставщика Roles API. Ранее уже было показано, как следует настраивать хранилище данных поставщика Roles API, используя для этого консоль управления IIS 8, где конфигурировались некоторые правила аутентификации для включения аутентификации с помощью форм для приложений ASP.NET и приложений, отличных от ASP.NET.

На рисунке ниже показано средство конфигурирования авторизации консоли управления IIS 8. В этом разделе мы углубимся в некоторые детали механизмов конфигурирования IIS 8.

Средство URL-авторизации IIS 8 работает совершенно независимо от ASP.NET, оно реализовано в отдельном встроенном HTTP-модуле, поставляемом с IIS 8. Как упоминалось ранее, он конфигурируется в отдельном разделе внутри файла web.config. Любое правило авторизации, которое настраивается через консоль управления IIS 8, добавляется в раздел <authorization> внутри раздела <system.webServer> файла web.config. Типичная конфигурация авторизации IIS 8 в файле web.config выглядит подобно приведенной ниже и концептуально работает точно так же, как правила авторизации ASP.NET:

<system.webServer>
    <security>
      <authorization>
        <remove users="*" roles="" verbs=""/>
        <add accessType="Deny" users="?"/>
        <add accessType="Allow" users="*"/>
      </authorization>
    </security>
</system.webServer>

Конфигурация внутри этого раздела подчиняется тем же правилам, что и конфигурация авторизации ASP.NET. IIS 8 обрабатывает эти правила сверху вниз, и как только находит соответствующее правило, немедленно останавливается. Опять-таки, не забудьте, что авторизация реализована в отдельном встроенном модуле UrlAuthorizationModule.dll, который поставляется вместе с IIS 8:

Почему важно понимать разницу? Прежде всего, UrlAuthorizationModule.dll можно использовать из IIS 8 независимо от ASP.NET. Когда веб-сервер IIS 8 установлен на машине, a ASP.NET - нет, URL-авторизацию по-прежнему можно использовать через встроенный модуль.

Однако вторая причина намного важнее для разработчика ASP.NET. Встроенный модуль URL-авторизации, поставляемый в составе IIS 8, способен корректно идентифицировать зарегистрированных пользователей, аутентифицированных всеми возможными модулями аутентификации, включая базовую аутентификацию, Windows-аутентификацию и даже аутентификацию с помощью форм. Это связано с тем, что модуль разработан таким образом, что он понимает билет аутентификации с помощью форм (закодированный либо в cookie-наборе, либо в строке запроса). Но, к сожалению, он не был реализован с учетом ролей ASP.NET.

Какова причина этого? Роли извлекаются инфраструктурой ASP.NET из хранилища на определенной стадии внутри жизненного цикла приложения (например, из базы данных, сконфигурированной для поставщика ролей). Информация о ролях затем инкапсулируется в управляемых объектах, реализующих интерфейс IPrincipal, и потому хранится в чистых управляемых объектах .NET, которые не доступны встроенным модулям IIS 8. Поэтому такие встроенные модули IIS 8, как UrlAuthorizationModule, не могут использовать эту информацию.

Таким образом, нельзя настраивать основанные на ASP.NET роли в сочетании с встроенным модулем URL-авторизации IIS 8 внутри элемента <authorization> в разделе <system.webServer>. В действительности это означает, что при использовании встроенного модуля UrlAuthorizationModule, поставляемого с IIS 8, можно применять только имена принципалов Windows Roles.

Как упоминалось ранее, в случае имен пользователей можно полностью полагаться на управление авторизацией IIS 8. Причина в том, что встроенный модуль реализован так, что он распознает пользователей, аутентифицированных встроенными модулями, и пользователей, аутентифицированных управляемыми модулями, такими как FormsAuthenticationModule. Чтобы использовать модуль FormsAuthenticationModule в сочетании с встроенным UrlAuthorizationModule, модуль FormsAuthentication должен быть разрешен для встроенной очереди обработки.

И, наконец, это означает, что авторизация на основе ролей является одним из нескольких исключений, где конфигурация IIS и ASP.NET все еще должна учитываться раздельно.

Авторизация с помощью ролей ASP.NET в IIS 8

Теперь известно, что встроенный модуль URL-авторизации, поставляемый с IIS 8, не понимает специфичной для ASP.NET информации о ролях, поскольку эта информация инкапсулирована в управляемых объектах, которые реализуют управляемые интерфейсы. С другой стороны, запуск IIS 8 в интегрированном режиме ASP.NET предоставляет унифицированный конвейер обработки HTTP, где встроенные и управляемые модули обрабатываются внутри одного конвейера HTTP-модулей. Поэтому для расширения поведения по умолчанию IIS 8 можно использовать любой управляемый HTTP-модуль, написанный на языке .NET по вашему выбору.

Это означает, что вы можете писать собственные HTTP-модули с помощью .NET и интегрировать их в конвейер обработки IIS 8. Но это также означает возможность интеграции существующих модулей ASP.NET, таких как FormsAuthentication или даже UrlAuthorization, непосредственно в конвейер обработки. Это позволит достичь следующих двух целей намного легче, чем в предыдущих версиях IIS:

• защитить ресурсы ASP.NET;

• использовать средства безопасности ASP.NET для любого веб-приложения, даже написанного не на ASP.NET.

Обе цели достигаются одинаковым способом - нужно просто разрешить управляемому модулю UrlAuthorization из ASP.NET работать в конвейере вместе с другими модулями IIS 8 (и модулями ASP.NET).

Эту опцию конфигурации можно включить с помощью средства конфигурирования модулей IIS 8, как показано на рисунке ниже:

Как только управляемый модуль UrlAuthorization включен, любой ресурс веб-сайта поступает под защиту системы безопасности ASP.NET. Это касается графических изображений, текстовых файлов или ресурсов любого другого типа, например, страниц классического ASP и даже PHP. Теперь можно конфигурировать роли авторизации для доступа ко всем этим ресурсам через конфигурационный раздел <authorization> внутри раздела <system.web> файла web.config.

На рисунке ниже демонстрируется мощь этого интегрированного способа обеспечения безопасности IIS 8 и ASP.NET:

Даже несмотря на то, что авторизация IIS 8 настроена так, что открывает любому доступ к сайту, всякий раз, когда браузер обращается к графическому изображению, из-за конфигурации авторизации ASP.NET он переадресуется на страницу входа аутентификации с помощью форм.

Конфигурация внутри web.config для случая, показанного на рисунке, выглядит примерно так:

<configuration>
  <system.web>
    <authorization>
       <deny users="?" />
    </authorization>
    <authentication mode="Forms">
      <forms loginUrl="MyLogin.aspx" />
    </authentication>
  </system.web>
  
  <system.webServer>
    <security>
      <authorization>
        <remove users="*" roles="" verbs=""/>
        <add accessType="Allow" users="*" roles=""/>
      </authorization>
    </security>
  </system.webServer>
  
  <system.webServer>
    <modules>
      <remove name="UrlAuthorization" />
      <remove name="FormsAuthentication" />
      <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" preCondition="" />
      <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" preCondition="managedHandler" />
    </modules>
  </system.webServer>
</configuration>

В приведенной выше конфигурации видно, что авторизация IIS 8 открывает доступ к веб-сайту любому пользователю, в то время как авторизация ASP.NET ясно запрещает доступ анонимным пользователям. Более того, конфигурация IIS 8 включает в конвейер обработки также модули FormsAuthenticationModule и UrlAuthorizationModule из ASP.NET, а это означает, что они будут влиять на доступ к любому ресурсу - основанному или не основанному на ASP.NET - внутри каталога веб-приложения. Это также означает, что для доступа к любому ресурсу, развернутому в веб-приложении IIS 8, можно полагаться на роли, управляемые ASP.NET, через Roles API и платформу Roles API.

Использование модуля UrlAuthorization из ASP.NET для конвейера обработки имеет смысл только тогда, когда не применяется аутентификация Windows. Причина в том, что с Windows-аутентификацией можно настраивать любые декларативные правила авторизации непосредственно в консоли управления IIS 8, и применять функциональность, предлагаемую встроенным модулем UrlAuthorizationModule, который поставляется в составе IIS 8.