SAML, инициированный AzureAD IDP, всегда возвращает nameid-format: persistent вместо nameid-format: emailAddress.
Я разрабатываю систему единого входа с использованием 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. Хотя я установил "формат идентификатора имени" как "Адрес электронной почты":
Обратите внимание, что в потоке, инициированном 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 поставщика услуг. Почему все еще есть запрос SAML? (При тестировании приложения в Azure я видел варианты загрузки запроса SAML). Когда я открываю приложение на панели приложений (office.com), я также вижу запрос SAML. (с использованием хромированного расширения saml-chrome-panel)
Я открыл заявку в службу поддержки Microsoft AzureAD. Я получил такой ответ от инженера Microsoft:
Я просмотрел вашу проблему и настройки приложения. Вы устанавливаете идентификатор имени в качестве атрибута почты и в формате электронной почты. Если я неправильно понимаю, пожалуйста, поправьте меня.
В случае, если у пользователя нет значения в атрибуте почты, Azure AD отправит постоянный формат для идентификатора имени и установит в нем случайное значение.
Поэтому, пожалуйста, проверьте, есть ли у пользователя значение в атрибуте mail.
В самом деле! У моего протестированного пользователя нет атрибута электронной почты! По словам специалиста службы поддержки Microsoft, он сказал, что из портала Azure мы не можем сказать, есть ли у тестируемого члена клиента электронная почта или нет:
Он сказал, что мы можем протестировать с помощью 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. Это действительно похоже на значение почты: user-email-address@foo.bar
Оказывается, когда mail равен нулю, он вернет userPrincipalName атрибут вместо этого.
Если мы хотим, чтобы член клиента существовал с атрибутом mail, этот клиент должен подписаться на почтовую службу или пакетный пакет, например Office 365, Exchange Online и т. Д. В этом случае мы не подписываемся ни на одну из них. Я думал, что просто создайте пользователя в Azure, и у этого пользователя уже есть электронная почта! Чтобы убедиться, я захожу на outlook.com и пытаюсь войти. Вот что у меня получилось:
