2014-11-14 4 views
0

Я разрабатываю прототип для приложения, которое мы планируем построить в MVC5, используя WIF 4.5, который будет проходить проверку подлинности на сервере ADFS. До сих пор я работаю над реализацией ADFS, однако существует требование разрешить пользователям в интрасети пассивно аутентифицироваться на определенном контроллере, скажем, контроллеру Admin, а внешние пользователи будут проходить проверку подлинности на домашнем контроллере с помощью ADFS. На первый взгляд я подумал, что это будет простая настройка web.config, однако, похоже, это не так..NET MVC5 с ADFS и аутентификацией Windows

ADFS НЕ находится в том же домене, что и приложение, однако я бы хотел, чтобы проверка подлинности Windows происходила в домене, в котором приложение отличается.

Мои вопросы: A) Возможно ли это, или я пытаюсь сделать что-то, с чем не предназначались рамки? Б) Как я могу это сделать?

Я попробовал несколько различных комбинаций

<location path="Admin"> 
    <system.web> 
    <!--Having this here throws an error--> 
    <authentication mode="Windows"></authentication> 
    <authorization> 
     <deny users="?" /> 
    </authorization> 
    </system.web> 
</location>` 

<system.web> 
    <authentication mode="None|Federated|Windows" /> 
    <authorization> 
    <deny users="?" /> 
    </authorization> 
    <compilation debug="true" targetFramework="4.5" /> 
    <httpRuntime targetFramework="4.5" requestValidationMode="4.5" /> 
</system.web> 

Оказывается, что, если какой-либо аутентификации применяются на практике, это всегда ADFS. Я запустил шаблон с помощью On-Premises Organizational Authentication Option (ADFS) With ASP.NET in Visual Studio 2013 и загрузил в него метаданные, из которых был предоставлен администратор. Таким образом, мой проект является более или менее ванильной реализацией этого шаблона с небольшим количеством настроек для использования пользовательского объекта, который я получаю из рабочего процесса ADFS.

Я получаю ошибку, что указано выше, если режим аутентификации установлен в узле местоположения является

Это ошибка использовать раздел, зарегистрированный в качестве allowDefinition = «MachineToApplication» вне уровня приложения. Эта ошибка может быть вызвана тем, что виртуальный каталог не настроен как приложение в IIS.

Кое-что связано с тем, что мой виртуальный каталог не установлен как приложение в IIS, но это не желаемый результат. Более того, когда я действительно пытался выполнить эту ошибку, у меня все еще не было проверки подлинности.

Немного больше деталей, после немного более изящного Я обнаружил, что настройки IISExpress (и в конечном итоге IIS) на самом деле должны быть установлены, что хорошо. Так Добавление

<location path="WebApplication4/Admin"> 
    <system.webServer> 
     <security> 
      <authentication> 
       <windowsAuthentication enabled="true" /> 
       <anonymousAuthentication enabled="false" /> 
      </authentication> 
     </security> 
    </system.webServer> 
</location> 

к моему ApplicationHost.config же начать побуждая браузер для имени пользователя и пароля, но я также обнаружил, что

<system.webServer> 
    <modules> 
     <add name="WSFederationAuthenticationModule" type="System.IdentityModel.Services.WSFederationAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" /> 
     <add name="SessionAuthenticationModule" type="System.IdentityModel.Services.SessionAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" /> 
    </modules> 
    </system.webServer> 

, кажется, что в конечном итоге полностью угон моей проверки подлинности, и заставляет все проходить через сервер ADFS. Я могу вручную вызвать методы аутентификации ADFS, поэтому то, что я хотел бы сделать, - это как-то сказать контроллеру не использовать это, а вместо этого использовать проверку подлинности Windows. Похоже, что если я просто прокомментирую эти модули, это сломает мой рабочий процесс ADFS, но затем он будет правильно использовать проверку подлинности Windows на контроллере администратора.

ответ

1

Вы не можете переопределить метод аутентификации для данного местоположения. У вас может быть только один метод проверки подлинности для вашего приложения.

Что касается Windows auth, он будет работать, только если сервер, на котором размещено приложение, находится в том же домене, что и ваши пользователи в интрасети, если у вас нет доверия между доменами.

Если у вас есть ADFS в вашей интрасети, вы можете установить федерацию между двумя экземплярами ADFS. Затем вы можете выполнить аутентификацию для внешних/внутренних пользователей.

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

Как вы можете догадаться, это не тривиальное решение для реализации, которое потребует дополнительной настройки инфраструктуры на внутренней стороне, если у вас нет ADFS.

Другим подходом будет предоставление ваших внутренних пользователей в вашем приложении. Это может быть более простой подход, если вам нужно предоставить только доступ нескольким пользователям.

+0

Спасибо за ответ, я думал, что это может быть так. Я думаю, что мне просто нужно разбить внутреннее приложение, чтобы быть его собственным приложением и справиться с ним вот так. –

+0

Я не верю, что утверждение «вы можете использовать только один метод аутентификации для вашего приложения». Глядя на это сообщение в блоге (я еще не пробовал), вы можете смешивать ADFS и аутентификацию форм вместе, пока они не находятся в одном месте (http://leastprivilege.com/2012/02/02/ mix-forms-and-token-authentication-in-a-single-asp-net-application /) – Bil

+0

Вы правы, вы можете каким-то образом скомпоновать некоторые схемы аутентификации с помощью какого-то настраиваемого кода. ASP.Net не предлагает вам такую ​​гибкость, и это то, что я имел в виду. @LazyCoder хотел просто переопределить схему аутентификации в теге местоположения, который не поддерживается, и вы не можете поместить файл web.config с другой схемой аутентификации. –

Смежные вопросы