URL-авторизация с использованием MVC и ASP.NET Identity

Question

URL-авторизация с использованием MVC и ASP.NET Identity

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

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

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

Тестовая среда

Я использую стандарт html файл для тестирования, вместо того, чтобы пытаться загрузить скрипт, так как он также будет загружен вне конвейера 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 каталога: один для аутентифицированной части приложения и один для неаутентифицированной части приложения. Причина этого не имеет ничего общего с авторизацией пользователя или безопасностью в приложении, а заключается в том, чтобы ограничить открытую поверхность приложения неаутентифицированными запросами.

15

asp.net asp.net-mvc asp.net-identity-2 asp.net-authorization

Источник

user1260204 27 фев '17 в 13:09

1 ответ

Решение

Другие вопросы по тегам asp.net asp.net-mvc asp.net-identity-2 asp.net-authorization

user2581562 02 мар '17 в 01:20 2017-03-02 01:20 · Accepted Answer · 2017-03-02 01:20

[TL;DR;]
Перейдите в раздел "Complete 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 по умолчанию будет применять правила разрешать и запрещать только к файлам, обрабатываемым управляемым обработчиком. Статические файлы не управляются управляемым обработчиком.

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

 <modules runAllManagedModulesForAllRequests="true">

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

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

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

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

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

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

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

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

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