ASP.NET MVC 2 и аутентификация с использованием WIF (Windows Identity Foundation)
Есть ли достойные примеры из следующих доступных:
Просматривая WIF SDK, можно найти примеры использования WIF в сочетании с ASP.NET с использованием WSFederationAuthenticationModule (FAM) перенаправить на тонкий слой сайта ASP.NET поверх службы маркеров безопасности (STS), которую пользователь использует для аутентификации (путем предоставления имени пользователя и пароля).
Если я правильно понимаю WIF и доступ на основе утверждений, я хотел бы, чтобы мое приложение предоставило собственный экран входа в систему, где пользователи вводят свои имя пользователя и пароль, и разрешил этому делегату STS для аутентификации отправлять данные для входа в конечную точку через стандарт безопасности. (WS-*) и ожидаем возврата токена SAML. В идеале SessionAuthenticationModule будет работать в соответствии с примерами, использующими FAM в сочетании с SessionAuthenticationModule т.е. нести ответственность за восстановление IClaimsPrincipal из файла cookie безопасности сеанса и перенаправления на страницу входа в мое приложение, когда сеанс безопасности истекает.
Возможно ли то, что я описываю, используя FAM а также SessionAuthenticationModule с соответствующими настройками web.config, или мне нужно подумать о написании HttpModule сам справиться с этим? В качестве альтернативы, происходит ли перенаправление на тонкий веб-сайт STS, где пользователи де-факто входят в систему в сценарии пассивного запросчика?
5 ответов
Пример 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) и не распространяется во многих приложениях. Но другое (огромное) преимущество заключается в том, что вы можете очень легко задействовать более сложные сценарии. Например, теперь вы можете объединяться с другими поставщиками удостоверений организации.
Надеюсь, это поможет Эухенио
@Восходящая звезда:
Маркер (содержащий утверждения) может быть зашифрован (в противном случае они будут в открытом тексте). Вот почему SSL всегда рекомендуется для взаимодействия между браузером и STS.
Обратите внимание, что, даже если они в открытом тексте, подделка невозможна, поскольку токен имеет цифровую подпись.
Это интересный вопрос, который вы задали. Я знаю, что по какой-то причине Microsoft выпустила эту платформу Windows Identity Foundation без особой документации. Я знаю это, потому что мне было поручено выяснить, как использовать его в новом проекте и интегрировать в существующую инфраструктуру. Я искал в Интернете в течение нескольких месяцев в поисках полезной информации.
Я принял несколько иной подход к решению проблемы, которую вы описываете.
Я взял существующее приложение для входа и подключил к нему WIF-систему Microsoft. Под этим я подразумеваю, что у меня есть приложение, в котором пользователь входит в систему. Приложение для входа в систему передает учетные данные, предоставленные пользователем, на другой сервер, который возвращает идентификатор пользователя (или указывает на ошибку входа в систему).
Глядя на некоторые примеры Microsoft, я вижу, что они делают следующее: SignInRequestMessage из строки запроса (созданной приложением проверяющей стороны) создайте службу токена безопасности из пользовательского класса и, наконец, вызовите FederatedSecurityTokenServiceOperations.ProcessSignInresponse с текущим httpcontext.response. К сожалению, я не могу объяснить это хорошо здесь; вам действительно нужно посмотреть на примеры кода.
Часть моего кода очень похожа на пример кода. Где вы будете заинтересованы в реализации большей части вашей собственной логики в GetOutputClaimsIdentity, Это функция, которая создает идентификатор заявок, который описывает вошедшего в систему пользователя.
Теперь вот что, я думаю, вы действительно хотите знать. Это то, что Microsoft не говорит вам в своей документации, AFAIK.
Когда пользователь входит в систему, он перенаправляется обратно в приложение проверяющей стороны. Независимо от того, как работает приложение для входа в систему, классы WIF отправят в браузер пользователя ответ, содержащий "скрытый" HTML-ввод, содержащий сертификат подписи токена и утверждения пользователя. (Претензии будут в открытом тексте). В конце этого ответа происходит перенаправление на ваш сайт проверяющей стороны. Я знаю только об этом действии, потому что я запечатлел его с "Fiddler"
Вернувшись на веб-сайт проверяющей стороны, классы 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 на страницу входа.
То, что вы хотите сделать, это активный вход. 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);
}
После этого ваш сайт должен вести себя так же, как если бы произошла пассивная подпись.
Вы можете использовать элемент управления FederatedPassiveSignIn.
Установка файла cookie следующим образом: FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(sessionToken); Не работает для единого входа в другие домены.
Для того, чтобы cookie должен быть установлен STS не на RP.