Мой поставщик услуг выдает SAML 2.0 AuthRequest с тегом NameIDPolicy следующим образом:
<samlp:NameIDPolicy AllowCreate="true"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
Это приводит к тому, что ADFS 2.0 правильно выдает ответ SAML, содержащий зашифрованный токен NameID, созданный правилом, аналогичным найденному. Вот
<NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
MyeHAMeGLojBt7fcc2DQtntXXFka0kybkR42ZTitTUs=</NameID>
Однако пока все хорошо, мой поставщик услуг, похоже, не понимает зашифрованное утверждение NameID и ожидает, что оно будет незашифрованным, в то же время имея формат имени как transient
Согласно этот документ, ADFS2.0 обрабатывает запросы временных или постоянных форматов NameID как сценарии конфиденциальности (и, следовательно, шифрование)
Итак, мой вопрос: есть ли способ заставить ADFS 2.0 сгенерировать утверждение NameID с Format = transient и незашифрованным NameID следующим образом:
<NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">Joe</NameID>
У нас был клиент, у которого возникла проблема с подключением к нашему веб-приложению. Мы хотели отключить шифрование, чтобы помочь отладить то, что мы получаем. Вот шаги, которые они использовали для отключения шифрования на своем сервере ADFS 2.0:
Затем в командной строке Windows PowerShell введите следующее:
set-ADFSRelyingPartyTrust –TargetName “target” –EncryptClaims $False
Я решил это следующим образом:
UPN к типу Исходящая претензия: Name ID и выберите transient nameid-format из раскрывающегося списка "Формат идентификатора исходящего имени"Это заставляет AD отправлять NameID в требуемом формате:
<NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">Joe</NameID>
(Я оставлю этот вопрос «без ответа» на время, если у кого-то есть лучшее решение.