ADFS с ASP.NET 4.5 и WIF Override NameClaimType

Я пытаюсь заставить ADFS работать с ASP.NET 4.5.2 и несколькими доменами. Пока сервер ADFS преобразует заявку с «upn» на «name», все работает правильно. Однако это невозможно в нескольких лесах AD, поэтому я должен выполнить преобразование на веб-сервере. Использование этой записи Web.Config должно заставить это преобразование.ADFS с ASP.NET 4.5 и WIF Override NameClaimType

<securityTokenHandlers> 
    <add type="System.IdentityModel.Tokens.Saml2SecurityTokenHandler, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"> 
     <samlSecurityTokenRequirement> 
     <nameClaimType value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" /> 
     </samlSecurityTokenRequirement> 
    </add> 
    </securityTokenHandlers>

Когда я отладки я считаю, что Thread.CurrentPrincipal.Identity.NameClaimType по-прежнему установлен в значение по умолчанию http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

Было бы полезно, если бы я мог определить, в C#, что активный SecurityTokenHandler используется.

Документация для ADFS несовместима. Что мне здесь не хватает?

источник

2015-12-08 user306031

Я бы захватил события и углубился в подробности. См. Https://msdn.microsoft.com/en-us/library/microsoft.identitymodel.web.wsfederationauthenticationmodule_events.aspx – Dhanuka777

У вас может быть локальный менеджер проверки подлинности запросов, который запускает разрешение на токен и там вы переписываете претензии в соответствии с вашими потребностями один раз. –

Эта документация ссылается на .NET 3.5, которая совершенно иная. – user306031

Проблема заключалась в том, что в нашей тестовой среде ADFS была настроена на возврат токенов SAML 2.0 и в токены SAML 1.1. Таким образом, конфигурация для Saml2SecurityTokenHandler даже не срабатывала.

Я обнаружил проблему, пытаясь настроить SamlSecurityTokenHandler, и преобразование было успешным.

источник

2015-12-09 17:21:46 user306031

ответ

Смежные вопросы