ASP.NET MVC 2 и аутентификация с использованием Wif (Foundation Identity Windows)
-
26-09-2019 - |
Вопрос
Есть ли какие-либо приличные примеры следующего доступного:
Просматривая Wif SDK, есть примеры использования WiF в сочетании с ASP.NET с помощью WSFederationAuthenticationModule (FAM)
Перенаправить на сайт ASP.NET тонкая кожа В верхней части службы безопасности безопасности (STS), которые пользователь использует для аутентификации (с помощью поставки имени пользователя и пароля).
Если я понимаю WiF и Actions-Access правильно, я хотел бы, чтобы мое приложение предоставить свой собственный экран входа в систему, когда пользователи предоставляют свое имя пользователя и пароль и пусть этот делегат на STS для аутентификации, отправив данные для входа в конечную точку через стандарт безопасности. (WS- *) и ожидаем возврата токена Saml. Идеально, то SessionAuthenticationModule
будет работать в соответствии с примерами, использующими FAM
в сочетании с SessionAuthenticationModule
то есть нести ответственность за реконструкцию IClaimsPrincipal
С сеансовой безопасности Cookie Cookie и перенаправляя к моей странице входа в систему приложения, когда истекает сеанс безопасности.
Это то, что я опишу, используя FAM
а также SessionAuthenticationModule
с соответствующими настройками web.config или мне нужно думать о написании HttpModule
Я, чтобы справиться с этим? В качестве альтернативы, перенаправляется на тонкий веб-сайт STS, где пользователи входят в систему DE FACTO в сценарии пассивного запроса?
Решение
Примером 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.aspx.
Управление опытом входа в систему идеально в порядке. Вы должны просто развернуть свои собственные STS (в вашем домене, со своим внешним видом и т. Д.). Ваши приложения просто полагаются на него для AUTHN (поэтому приложение обычно называют «полагающейся стороной»).
Преимущество архитектуры заключается в том, что AUTHN делегируется до 1 компонента (STS) и не распространяется на протяжении многих приложений. Но другое (огромное) преимущество состоит в том, что вы можете очень легко включить более сложные сценарии. Например, теперь вы можете создать федерацию с другими поставщиками личности других организаций.
Надеюсь, это поможет Евгению
@Восходящая звезда:
Токен (содержащий претензии) может быть необязательно зашифрован (в противном случае они будут в четком тексте). Вот почему SSL всегда рекомендуется для взаимодействия между браузером и STS.
Обратите внимание, что, хотя они находятся в четком тексте, вмешательство невозможно, потому что токен в цифровом подписании.
Другие советы
Это интересный вопрос, который вы спросили. Я знаю, что по какой-либо причине Microsoft выпустила эту «Фонд Windows Identity Foundation» без особой документации. Я знаю это, потому что мне было поручено выяснять, как использовать его с новым проектом и интегрировать его с существующей инфраструктурой. Я искал в Интернете в течение нескольких месяцев, ища хорошую информацию.
Я взял несколько разных угол для решения проблемы, которую вы описываете.
Я взял существующую вход в систему приложения и интегрировал в него сантехнику Microsoft WiF. Этим, я имею в виду, что у меня есть приложение, в котором пользователь входит в систему. Приложение входа в систему подает учетные данные, предоставляемые пользователем на другой сервер, который возвращает идентификацию пользователей (или указывает сбой входа в систему).
Глядя на некоторые из примеров Microsoft, я вижу, что они делают следующее: построить SignInRequestMessage
Из кригента (сгенерировано приложением полагаемой партии), построить службу безопасности в соответствии с пользовательским классом и, наконец, вызови федеративныхsecuritytokenserviceOperations.processsignInSeponseSponse с текущим httpcontext. К сожалению, я не могу объяснить это хорошо здесь; Вам действительно нужно посмотреть на образцы кода.
Некоторый мой код очень похож на образец кода. Где вы собираетесь заинтересовать в реализации множества вашей собственной логики, находится в GetOutputClaimsIdentity
. Отказ Это функция, которая создает идентификацию претензий, которые описывают вошедший пользователь.
Теперь, вот что я думаю, вы действительно заинтересованы в том, чтобы знать. Это то, что Microsoft не говорит вам в своей документации, AFAIK.
Как только пользователь входит в систему, они перенаправлены обратно в приложение для полагающейся стороны. Независимо от того, как работает входное приложение, классы WiF отправит ответ на браузер пользователя, который содержит «скрытый» HTML-вход, который содержит сертификат подписания токена и претензии пользователя. (Претензии будут в четком тексте). В конце этого ответа находится перенаправление на ваш веб-сайт полагающейся сторон. Я только знаю об этом действии, потому что я схватил его с "Fiddler"
Однажды обратно на веб-сайте Partying Party, классы WiF будут обрабатывать ответ (до того, как любой из вашего кода запускается). Сертификат будет подтвержден. По умолчанию, если вы настроили свой веб-сайт Partying Party с FedUtil.exe (нажав кнопку «Добавить ссылку на STS в приложении BeLying Party из Visual Studio), класс Microsoft проверит отпечаток сертификата.
Наконец, WiF Framework устанавливает файлы cookie в браузере пользователя (в моем опыте, имена cookie начинаются с «Fedauth»), которые содержат претензии пользователя. Печенье не читаемо человеком.
Как только это произойдет, вы можете необязательно выполнить операции по претензиям пользователя в сайте полагающейся сторон, используя ClaimsAuthenticationClass
. Отказ Это где ваш код снова работает.
Я знаю, что это отличается от того, что вы описываете, но у меня есть эта настройка. Надеюсь, это поможет!
придавать Пожалуйста, ознакомьтесь с другими вопросами, которые я спросил о фундаменте Identity Windows.
Обновление: ответить на вопрос в комментарии ниже:
Одна вещь, которую я покинул, - это то, что перенаправление на приложение Log-STS происходит с помощью перенаправления с помощью строки запроса, содержащей URL-адрес приложения, в который пользователь входит в систему. Этот перенаправление происходит автоматически в первый раз, когда пользователь пытается получить доступ к странице, которая требует аутентификации. В качестве альтернативы, я считаю, что вы могли бы сделать перенаправить вручную с WSFederationAuthentication
модуль.
Я никогда не пытался это сделать, но если вы хотите использовать страницу входа в систему в самом приложении, я полагаю, что структура должна позволить вам использовать следующее:
1) инкапсулировать код вашего STS в библиотеке. 2) Ссылайте библиотеку из вашего приложения. 3) Создайте страницу входа в систему в своем приложении. Убедитесь, что такая страница не требует аутентификации. 4) Установите свойство эмитента wsFederation
элемент внутри Microsoft.IdentityModel
Раздел вашего web.config на страницу входа в систему.
То, что вы хотите сделать, это активный сигнал. Wif включает в себя WTRUSTCHANNEL (Фабрика) Что позволяет вам общаться напрямую с STS и получить токен безопасности. Если вы хотите, чтобы ваша форма входа в систему работать таким образом, вы можете следить за образцом «WTRUSTChannel» из 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);
}
Как только вы сделаете это, ваш сайт должен вести себя так же, как если бы произошла пассивная подписание.
Вы можете использовать управление федеративным трассами.
Установка вашего файла cookie: FederatedAuthentication.sessionauthenticationModule.writeSesstokentocoodie (SessionToken); Не работает для SSO в другие домены.
Для Cookie следует установить STS не на RP.