Авторизация URL с идентификаторами MVC и ASP.NET

Я хочу защитить определенные папки и ресурсы в своем приложении, которые находятся за пределами маршрутов моего приложения mvc. Я хочу, чтобы эти ресурсы были доступны только для аутентифицированных пользователей (роль которых не в поведении, если они аутентифицированы).

Первоначально казалось, что ответ UrlAuthorizationModule. Я прочитал эту статью, Понимание авторизации URL-адреса IIS 7.0, и я могу заставить модуль работать в том смысле, что он отвечает на элементы конфигурации в web.config.

Моя текущая проблема заключается в том, что я думаю принимает правила, основанные на анонимном пользователе в IIS, а не аутентифицированный пользователь в asp.net identity.

Условия тестирования

Я использую стандартный файл html для тестирования вместо того, чтобы пытаться загрузить script, поскольку он также будет загружен за пределы конвейера MVC.

  • В Visual Studio 2015.
    • Новый веб-проект .net 4.6.2
    • Шаблон MVC
    • Аутентификация = Individual User Accounts
  • IIS 8 (для тестирования вне Visual Studio)
    • Аутентификация → Анонимная аутентификация (включена)

Добавить в web.config

<configuration>
...
<location path="Data">
  <system.webServer>
    <security>
      <authorization>
        <clear/>
        <add accessType="Deny" users="*"/>
        <add accessType="Allow" users="?"/>
      </authorization>
    </security>
  </system.webServer>
</location>
...
</configuration>

Добавить в структуру папок

/Data/Protected.html // this file just has some basic Hello World content to display so you can see if it is loaded or not.

Наблюдаемые результаты

  • В этой конфигурации все в пути Data всегда отрицается, не имеет значения, аутентифицирован ли пользователь или нет.
  • То же самое верно, если я переключу 2 строки для Deny и Allow в web.config.
  • Если я полностью удаляю строку с помощью Deny, доступ всегда разрешается даже тогда, когда пользователь не аутентифицируется.
  • Если я добавлю роль и использую roles с именем роли вместо атрибута users, роль также полностью игнорируется.

Теперь что?

Что мне не хватает? Как я могу получить модуль Url Authorization для работы с MVC/WebAPI и asp.net identity Individual User Accounts или это просто не выполнимо?

Я также открыт для альтернативных идей, может быть, ответ заключается в написании пользовательских HttpModule или HttpHandler?

Боковые заметки

Почему и специфика

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

Ответы

Ответ 1

[TL; DR;]
Перейдите в раздел "Полный root web.config" , чтобы увидеть необходимую настройку web.config.

Проверьте это в режиме инкогнито, чтобы предотвратить проблемы кэширования браузера! И используйте Ctrl+F5, потому что скрипты и html файлы становятся кэшированными.

Сначала запретите доступ ко всем анонимным пользователям в корневом web.config.

<authorization>
    <deny users="?"/>        
</authorization>

Здесь web.config позволяет одной папке публично доступной. Эта папка в моем примере здесь называется css и находится в корневом каталоге приложения MVC. Для папки css я добавляю следующую авторизацию в корневой web.config:

<location path="css">
    <system.web>
        <authorization>          
            <allow users="*"/>
        </authorization>
    </system.web>
</location>

Вы можете добавить больше этих путей расположения, если хотите больше общих папок.

Пока все остальные файлы не будут доступны, пока пользователь не войдет в систему, папка css и ее содержимое всегда будут доступны.

Я также добавил статический обработчик файлов в корневой web.config, Это очень важно, так как вы хотите, чтобы запрос управлялся конвейером asp.net для определенного типа (ов) файла

<handlers>
    <add name="HtmlScriptHandler" path="*.html" verb="*" preCondition="integratedMode" type="System.Web.StaticFileHandler" />
</handlers>

Полный корневой web.config

<system.web>
    <authentication mode="None" />
    <authorization>
        <deny users="?"/>        
    </authorization>
    <compilation debug="true" targetFramework="4.6.2" />
    <httpRuntime targetFramework="4.6.2" />
</system.web>
<location path="css">
    <system.web>
        <authorization>          
            <allow users="*"/>
        </authorization>
    </system.web>
</location>
<system.webServer>
    <modules>
        <remove name="FormsAuthentication" />           
        <remove  name="UrlAuthorization" />
        <add  name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule"  />     
    </modules>
    <handlers>
        <add name="HtmlScriptHandler" path="*.html" verb="*" preCondition="integratedMode" type="System.Web.StaticFileHandler" />
    </handlers>      
</system.webServer>

ASP.NET по умолчанию будет применять правила allow и deny к файлам, обрабатываемым управляемым обработчиком. Статические файлы не управляются управляемым обработчиком.

Вы также можете установить: (Не делать этого, если не нужно!)

 <modules runAllManagedModulesForAllRequests="true">

С runAllManagedModulesForAllRequests="true" все HTTP-модули будут выполняться на каждом запросе, а не только на управляемые запросы (например,.aspx, ashx). Это означает, что модули будут выполняться на каждом запросе .jpg,.gif,.css,.html,.pdf,....

Одна важная вещь
Вам не нужно добавлять модуль UrlAuthorizationModule в раздел модулей, поскольку он уже является частью конвейера ASP.NET. Это означает, что он будет работать только для управляемых файлов, а не для статичных!

Если вы теперь удалите, а затем снова добавите UrlAuthorizationModule в раздел модулей, он будет работать в предварительном режиме "IntegratedMode", а не под "managedHandler" больше! И, следовательно, будет иметь доступ к статическим файлам.

<remove  name="UrlAuthorization" />
<add  name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />

Если вы настроили предварительное условие: <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" preCondition="managedHandler" />, тогда UrlAuthorizationModule больше не будет ограничивать доступ к статическим файлам.

Вы можете протестировать это, получив доступ к файлу script в папке сценариев успешно во время выхода из системы. Нажмите Ctrl + F5, чтобы получить новую копию файла script.

Разница между ASP.NET UrlAuthorization ↔ Авторизация URL IIS

Важно иметь в виду, что предусловие managedHandler находится в модуле UrlAuthorization ASP.NET. Предварительное условие говорит вам что модуль авторизации URL-адреса вызывается только тогда, когда код, который обрабатывает запрос, сопоставляется с управляемым кодом, как правило,.aspx или .asmx page. С другой стороны, авторизация URL-адреса IIS распространяется на все содержание. Вы можете удалить предварительное условие managedHandler из Модуль авторизации URL-адресов ASP.NET. Это должно предотвратить производительность вы должны платить, когда каждый запрос (например, запрос .html или .jpg) должны пройти управляемый код.

P.S.: Некоторые атрибуты web.config чувствительны к регистру!