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, где пользователи регистрируют де-факто подход в сценарии пассивного запроса?

Ответ 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.

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

Ответ 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 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);
}

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

Ответ 4

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

Ответ 5

Настройка вашего файла cookie следующим образом: FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(sessionToken); Doens't не работает для SSO в других доменах.

В cookie должен быть установлен STS не на RP.