ASP.NET MVC 2 и аутентификация с использованием WIF (Windows Identity Foundation)

Question

Существуют ли приличные примеры из следующих доступных:

Просматривая WIF SDK , есть примеры использования WIF в сочетании с ASP.NET с использованием WSFederationAuthenticationModule (FAM) для перенаправления на сайт ASP.NET thin skin поверх службы маркеров безопасности (STS), которую пользователь использует для аутентификации (путем ввода имени пользователя и пароля).

Если я правильно понимаю WIF и доступ на основе утверждений, я хотел бы, чтобы мое приложение предоставило собственный экран входа в систему, где пользователи вводят свои имя пользователя и пароль, и разрешил этому делегату STS для аутентификации отправлять данные для входа в конечную точку через стандарт безопасности (WS- *) и ожидание возврата токена SAML. В идеале SessionAuthenticationModule будет работать в соответствии с примерами, использующими FAM в сочетании с SessionAuthenticationModule, т.е. отвечать за восстановление IClaimsPrincipal из фрагментированного cookie безопасности сеанса и перенаправление на страницу входа в мое приложение, когда сеанс безопасности истечет.

Возможно ли то, что я описываю, используя FAM и SessionAuthenticationModule с соответствующими настройками web.config, или мне нужно подумать о написании HttpModule для себя? В качестве альтернативы, происходит ли перенаправление на тонкий веб-сайт STS, где пользователи де-факто входят в систему в сценарии пассивного запросчика?

Answer 1

Пример WIF + MVC доступен в этой главе «Руководства по идентификации претензий»:

http://msdn.microsoft.com/en-us/library/ff359105.aspx

Я предлагаю прочитать первые пару глав, чтобы понять все основные принципы. В этом блоге рассказывается о специфике MVC + WIF:

http://blogs.msdn.com/b/eugeniop/archive/2010/04/03/wif-and-mvc-how-it-works.aspx

Управление входом в систему совершенно нормально. Вы должны просто развернуть свой собственный STS (в своем домене, с вашим внешним видом и т. Д.). Ваши приложения будут просто полагаться на него для AuthN (вот почему приложение обычно называют «проверяющей стороной»).

Преимущество архитектуры заключается в том, что authN делегируется одному компоненту (STS) и не распространяется во многих приложениях. Но другое (огромное) преимущество заключается в том, что вы можете очень легко задействовать более сложные сценарии. Например, теперь вы можете объединяться с другими поставщиками удостоверений организации.

Надеюсь, это поможет Eugenio

@ RisingStar:

Маркер (содержащий утверждения) может быть зашифрован (в противном случае они будут в открытом тексте). Вот почему SSL всегда рекомендуется для взаимодействия между браузером и STS.

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

Answer 2

Это интересный вопрос, который вы задали. Я знаю, что по какой-то причине Microsoft выпустила эту платформу Windows Identity Foundation без особой документации. Я знаю это, потому что мне было поручено выяснить, как использовать его в новом проекте и интегрировать в существующую инфраструктуру. Я искал в Интернете в течение нескольких месяцев в поисках полезной информации.

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

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

Глядя на некоторые примеры Microsoft, я вижу, что они делают следующее: Создайте SignInRequestMessage из строки запроса (созданной приложением проверяющей стороны), создайте службу маркеров безопасности из пользовательского класса и, наконец, вызовите FederatedSecurityTokenServiceOperations.ProcessSignInresponse с текущим httpcontext.response. К сожалению, я не могу объяснить это хорошо здесь; вам действительно нужно взглянуть на примеры кода.

Часть моего кода очень похожа на пример кода. Где вы будете заинтересованы в реализации большей части вашей собственной логики - в GetOutputClaimsIdentity. Это функция, которая создает идентификатор заявок, который описывает вошедшего в систему пользователя.

Теперь вот что, я думаю, вы действительно хотите знать. Это то, что Microsoft не сообщает вам в своей документации, AFAIK.

Когда пользователь входит в систему, он перенаправляется обратно в приложение проверяющей стороны. Независимо от того, как работает приложение для входа в систему, классы WIF отправят в браузер пользователя ответ, содержащий «скрытый» HTML-ввод, содержащий сертификат подписи токена и утверждения пользователя. (Претензии будут в открытом тексте). В конце этого ответа происходит перенаправление на ваш сайт проверяющей стороны. Я знаю об этом действии только потому, что запечатлел его с помощью «Скрипача»

Вернувшись на веб-сайт проверяющей стороны, классы WIF будут обрабатывать ответ (до запуска любого вашего кода). Сертификат будет подтвержден. По умолчанию, если вы настроили веб-сайт проверяющей стороны с помощью FedUtil.exe (нажав «Добавить ссылку на STS в приложении проверяющей стороны из Visual Studio), класс Microsoft проверит отпечаток сертификата.

Наконец, инфраструктура WIF устанавливает файлы cookie в браузере пользователя (по моему опыту имена файлов cookie начинаются с «FedAuth»), которые содержат утверждения пользователей. Печенье не читается человеком.

Как только это произойдет, вы можете по желанию выполнить операции с претензиями пользователя на веб-сайте проверяющей стороны, используя ClaimsAuthenticationClass. Здесь ваш код снова выполняется.

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

пс. Пожалуйста, ознакомьтесь с другими вопросами, которые я задавал о Windows Identity Foundation.

ОБНОВЛЕНИЕ: Чтобы ответить на вопрос в комментариях ниже:

Одна вещь, которую я упустил, заключается в том, что перенаправление в приложение входа в систему STS происходит путем перенаправления со строкой запроса, содержащей URL-адрес приложения, в которое входит пользователь. Это перенаправление происходит автоматически при первом обращении пользователя к странице, требующей аутентификации. Кроме того, я считаю, что вы можете сделать перенаправление вручную с помощью модуля WSFederationAuthentication.

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

1) Инкапсулируйте ваш код STS в библиотеке. 2) Ссылка на библиотеку из вашего приложения. 3) Создайте страницу входа в свое приложение. Убедитесь, что такая страница не требует аутентификации.4) Задайте для свойства входа элемента wsFederation в разделе Microsoft.IdentityModel вашего web.config страницу входа.

Answer 3

То, что вы хотите сделать, это активный вход. WIF включает WSTrustChannel (Factory) , который позволяет напрямую связываться с STS и получать токен безопасности. Если вы хотите, чтобы ваша форма входа работала таким образом, вы можете воспользоваться примером «WSTrustChannel» из WIF 4.0 SDK. После получения токена следующий код возьмет этот токен и вызовет обработчик WIF для создания токена сеанса и установки соответствующего файла cookie:

public void EstablishAuthSession(GenericXmlSecurityToken genericToken)
{
    var handlers = FederatedAuthentication.ServiceConfiguration.SecurityTokenHandlers;            
    var token = handlers.ReadToken(new XmlTextReader(
                                        new StringReader(genericToken.TokenXml.OuterXml)));

    var identity = handlers.ValidateToken(token).First();
    // create session token
    var sessionToken = new SessionSecurityToken(
        ClaimsPrincipal.CreateFromIdentity(identity));
    FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(sessionToken);
}

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

Answer 4

Вы можете использовать элемент управления FederatedPassiveSignIn.

Answer 5

Установка вашего куки так: FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie (sessionToken); Не работает для единого входа в другие домены.

Для того, чтобы cookie-файлы должны быть установлены STS, а не на RP.