Обычно происходит то, что вас перенаправляют только один раз, происходит танец перенаправления (пассивное перенаправление), и вы получаете токен. Токен обычно кэшируется в файле cookie в зашифрованном формате. Таким образом, последующие запросы не танцуют перенаправления.
Проблема здесь в том, что, поскольку файл cookie зашифрован, все серверы в веб-ферме должны иметь ключ шифрования для дешифрования. Из коробки вы столкнетесь с проблемами с WIF, потому что по умолчанию он использует DPAPI. Этот тип шифрования намеренно различается для разных машин. Это ломается в облаке.
Что вам нужно сделать, так это загрузить сертификат службы как часть вашего развертывания и изменить способ шифрования файлов cookie на что-то удобное для веб-фермы. Вот магический код:
private void OnServiceConfigurationCreated(object sender,
ServiceConfigurationCreatedEventArgs e)
{
var sessionTransforms =
new List<CookieTransform>(
new CookieTransform[]
{
new DeflateCookieTransform(),
new RsaEncryptionCookieTransform(
e.ServiceConfiguration.ServiceCertificate),
new RsaSignatureCookieTransform(
e.ServiceConfiguration.ServiceCertificate)
});
var sessionHandler = new
SessionSecurityTokenHandler(sessionTransforms.AsReadOnly());
e.ServiceConfiguration.SecurityTokenHandlers.AddOrReplace(
sessionHandler);
}
Это настраивает обработчик токенов безопасности для использования шифрования RSA с ключевыми материалами, полученными из установленного сертификата.
В этом примере приложения приведены более подробные сведения и информация, которые иллюстрируют проблему и решение:
http://msdn.microsoft.com/en-us/library/ff966481.aspx
Дополнительное редактирование:
В ASP.NET есть конвейер, в котором настроен WIF. Он перехватывает событие аутентификации, извлекает токен из файла cookie и создает ваш IPrincipal, чтобы последующий код имел его в контексте. Обычно вы не создаете Принципала самостоятельно при использовании STS. Вместо этого, если вам нужно изменить принципала, вы подключаетесь к конвейеру в WIF и вставляете дополнительные утверждения в утверждение «роль» (на самом деле пространство имен URI). Затем WIF будет использовать эти утверждения для создания ClaimsPrincipal, который будет содержать такие вещи, как роли, и все, что просто работает (IsInRole, web.config auth и т. Д.).
Если возможно, лучше всего, чтобы токен содержал роли в качестве утверждений. Однако это гораздо более длинная дискуссия о «нормализации» требований к значимым контекстам. Помните, что утверждения, которые вы получаете от IP-STS, сформулированы сами по себе и могут ничего не значить для вашего приложения. Например, я могу получить утверждение от клиента о том, что он входит в группу Adatum \ Managers. Это совершенно бессмысленно для моего приложения, поэтому я обычно обмениваю этот токен на тот, который понимает мое приложение, и в процессе трансформирую или нормализую утверждения с помощью сопоставлений утверждений (например, Adatum \ Managers -> MyApplicationAdminRole). Служба Windows Azure ACS очень применима, чтобы помочь в этом (нормализовать заявки с разных IP-адресов).
Я бы рекомендовал прочитать об этом книгу Витторио, получите общие шаблоны здесь:
Примечания Эухенио: Добавление к тому, что написал @dunnry, и это все правильно. Правильная точка расширения для расширения вашего утверждения, установленного в проверяющей стороне (вашем веб-приложении), - это использование ClaimsAuthenticationManager. Документация для этого типа находится здесь. на этой странице есть указатели на образцы. В этом классе вы читаете роли из XML-файла и добавляете их в ClaimsIdentity. Остальная часть приложения не будет беспокоиться о претензиях и т. Д. (Особенно, если вы используете роли, как в вашем случае). Конфигурация RSA для шифрования файлов cookie решает проблему балансировщика нагрузки.
person
dunnry
schedule
25.10.2011
