Запущенный AzureAD IDP SAML всегда возвращает nameid-format: постоянный вместо nameid-format: emailAddress - PullRequest
Новая
       78

Запущенный AzureAD IDP SAML всегда возвращает nameid-format: постоянный вместо nameid-format: emailAddress

0 голосов
/ 05 марта 2020

Я разрабатываю SSO с использованием SAML, и мой IdP равен Azure.

У меня проблема с потоком, инициированным IDP. В ответе SAML я всегда получаю этот NameID: 

<NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
    bMFy2VsLxPyxxxxxx.....
</NameID>

Это то, что я ожидаю: 

<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
    user-email-address@foo.bar
</NameID>

Я всегда получаю nameid-format:persistent вместо nameid-format:emailAddress. Хотя я установил «формат идентификатора имени» как «Адрес электронной почты»:

enter image description here

Обратите внимание, что на потоке, инициированном SP, я мог получить Azure отправить адрес электронной почты, указав NameIDPolicy: 

<samlp:AuthnRequest
        Destination="xxx"
        ID="_f59f9e55bc165eae92e4269909e274aeb78f88f3" 
        IssueInstant="2020-03-04T10:49:51Z" Version="2.0"
        xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
        xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
  <saml:Issuer>xxxxxxx</saml:Issuer>
  <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/>
</samlp:AuthnRequest>

Однако в потоке, инициированном IdP, AuthnRequest не имеет NameIDPolicy 

<samlp:AuthnRequest xmlns="urn:oasis:names:tc:SAML:2.0:metadata" 
                    ID="F84D888AA3B44C1B844375A4E8210D9E" Version="2.0"
                    IssueInstant="2020-03-04T10:03:47.953Z" IsPassive="false"
                    AssertionConsumerServiceURL="xxxxxx"
                    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
                    ForceAuthn="false">
  <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">xxxxxx</Issuer>
</samlp:AuthnRequest>

Мне интересно, есть ли в конфигурации моего приложения Azure что-то не правильно.

Кстати, о потоке, инициированном IdP, я думал, что IdP создаст ответ SAML и отправит его прямо на конечную точку ACS SP. Почему все еще есть запрос SAML? (При тестировании приложения на Azure я мог видеть варианты загрузки запроса SAML). Когда я открывал приложение из панели приложений (office.com), я тоже мог видеть запрос SAML. (используя chrome расширение saml- chrome -панель)

enter image description here

Ответы [ 2 ]

0 голосов
/ 09 марта 2020

Я открыл заявку в службу поддержки в Microsoft AzureAD. Я получил ответ от инженера Microsoft:

Я посмотрел проблему, с которой вы столкнулись, и настройки приложения. Вы устанавливаете Имя ID как атрибут почты и в формате электронной почты. Если я понимаю, что это неправильно, пожалуйста, исправьте меня.

В случае, если у пользователя нет значения в почтовом атрибуте, тогда Azure AD отправит постоянный формат для идентификатора имени и установит в нем случайное значение ,

Поэтому, пожалуйста, проверьте, имеет ли пользователь значение в своем почтовом атрибуте.

Действительно! Мой проверенный пользователь не имеет атрибута электронной почты! По словам сотрудника службы поддержки Microsoft, он сказал, что на портале Azure мы не можем сказать, что у протестированного участника есть электронная почта или нет:

![image.png (116.9 kB)](https://files.esa.io/uploads/production/attachments/2264/2020/03/06/45820/9d91c9d7-ed6c-470a-948d-82203c11faea.png)

Он сказал, что мы можем протестировать с помощью PowerShell или Azure CLI: 

$ Get-AzureADUser -ObjectId <Object ID of the user>
# or
$ az ad user show --id <Object ID of the user>

{
  ...
  "jobTitle": null,
  "lastDirSyncTime": null,
  "legalAgeGroupClassification": null,
  "mail": null,
  "mobile": null,
  "objectId": ....
}

У тестируемого пользователя нет почтового атрибута. Так что поведение ожидается.

Но мне все еще интересно, какое значение возвращает IdP в потоке, инициированном SP. Это действительно похоже на значение mail: user-email-address@foo.bar

Оказывается, что когда mail имеет значение null, вместо него возвращается атрибут userPrincipalName.

Если мы хотим, чтобы член-арендатор существовал с атрибутом mail, то арендатор должен подписаться на почтовую службу или пакет, такой как Office 365, Exchange Online и т. д. c. В этом случае мы не подписываемся ни на что. Я думал, что просто создайте пользователя в Azure, и у этого пользователя уже есть электронная почта! Просто чтобы убедиться, я go на outlook.com и пытаюсь войти. Вот что я получил:

enter image description here

0 голосов
/ 05 марта 2020

Попробуйте использовать поток, инициированный IdP, с NameIDPolicy

<samlp:AuthnRequest
xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
ID="id6c1c178c166d486687be4aaf5e482730"
Version="2.0" IssueInstant="2013-03-18T03:28:54.1839884Z"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://www.contoso.com</Issuer>
<samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">
  </samlp:NameIDPolicy>
</samlp:AuthnRequest>

Более подробную информацию можно найти в этой статье (перевод на английский sh).

...