2016-03-09 7 views
0

Я хотел бы получить гибрид Windows & Проверка подлинности форм для наших веб-приложений ASP.NET. Я видел детали нескольких способов сделать это, некоторые из Stackoverflow, от простых перенаправлений до решения OWIN, которое выглядит довольно страшно, и я честно не могу следить за тем, что происходит! Я мог бы действительно использовать некоторые советы по архитектуре, пожалуйста!Гибридная проверка подлинности Windows + Forms в приложениях ASP.Net. Просьба получить архитектурный совет

В настоящее время у нас есть несколько веб-приложений (все под одним корневым доменом), все с использованием проверки подлинности форм. Пользователи перенаправляются в одно приложение проверки подлинности, которое проверяет их учетные данные и проверяет, что им предоставлен доступ к приложению, которое они хотят использовать. Веб-сервер открыт для публики, размещается в DMZ во внешнем центре обработки данных.

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

Обзор того, что я читал о до сих пор:

  • Простой редирект.

такие подходы, как это - https://msdn.microsoft.com/en-us/library/ms972958.aspx и http://mvolo.com/iis-70-twolevel-authentication-with-forms-authentication-and-windows-authentication/ - до сих пор используют проверку подлинности форм. Но целевой URL входа в систему является страницей aspx, которая защищена с помощью проверки подлинности Windows. Пользователи, прошедшие проверку подлинности домена, могут получить доступ к этой странице, поэтому имя пользователя Windows можно снять и использовать для создания обычного билета. Пользователи, не являющиеся доменными, получат ошибку с разрешением 401, при которой IIS настроен на перенаправление таких ошибок на обычную форму проверки подлинности.

Это похоже на простой подход, но я думаю, что (а) это не сработает для меня, потому что веб-сервер находится в DMZ, который не имеет доступа к нашему AD и (b) большинство ссылок на эту технику кажутся вполне старый, поэтому я думаю, что это устаревший подход.

  • Windows Identity Foundation.

Мне очень нравится этот подход. Я прошел через некоторые материалы о Pluralsight, но наше точное требование не охвачено. У нас есть AD FS 2.0 (скоро будет обновлено до 3.0, я понимаю). Было бы возможно, чтобы пользователи домена, направленные в AD FS, выступая в роли STS, получали токен, но не-доменные пользователи, направленные на простой STS в DMZ для аутентификации имени пользователя и пароля? Из диаграмм, которые я видел, видно, что WIF может доверять нескольким STS, но может ли пользователь автоматически перенаправляться на конкретную STS в зависимости, например, от IP-адреса или другого способа распознавания внутреннего/внешнего доступа?

Кроме того, я видел довольно много Powerpoints по этой теме, но кто-то мог указать мне в сторону некоторых конкретных примеров, поскольку я, похоже, не могу их найти.

  • OWIN/Katana.

Теперь это будет предпочтительным способом, с новыми проектами ASP.NET, которые будут добавлены с самого начала. Опять же, я смотрел несколько видеороликов Pluralsight. Я придерживался идеи конвейера запросов и промежуточного программного обеспечения (я использовал BizTalk так, чтобы концепция была знакома).Но я потерял сюжет, когда он получил промежуточное ПО для аутентификации. Мне придется пересмотреть материал. Я нашел этот код, который говорит, что он делает то, что я хочу - https://github.com/MohammadYounes/MVC5-MixedAuth/tree/WindowsFirst - но, честно говоря, это было вне моего понимания.

Может кто-нибудь, пожалуйста, сообщите мне, можно ли использовать Katana для достижения того, что я хочу, и есть ли более простой метод, чем используемый в этом примере кода?

Итак, в целом, я думаю, я мог бы использовать некоторые советы о том, какие из этих подходов я должен использовать. Или есть лучший способ? Заранее спасибо.

ответ

0

Простейшим решением является установка прокси-сервера ADFS/WAP.

Затем, используя разделенный DNS, внешние пользователи перенаправляют на прокси (FBA) и внутренние пользователи перенаправляются во внутреннюю ADFS (IWA).

Проблема с WIF/OWIN и т. Д. Заключается в том, что они доставляют вас в ADFS, но они не определяют способ аутентификации ADFS.

+0

Hi. Большое спасибо за помощь. Я продолжу это предложение. Даг. – Doug