Azure AD IDP 始终启动 SAML return nameid-format: 持久性而不是 nameid-format: 电子邮件地址
AzureAD IDP Initiated SAML always return nameid-format:persistent instead of nameid-format:emailAddress
我正在使用 SAML 开发 SSO,我的 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
。
虽然我已经将 "name identifier format" 设置为 "Email address":
请注意,在 SP 启动的流程中,我可以通过指定 NameIDPolicy 让 Azure 发送电子邮件地址:
<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 响应并直接发送到 SP 的 ACS 端点。为什么还有SAML请求? (在 Azure 上测试应用程序时,我可以看到下载 SAML 请求的选项)。当我从应用程序面板 ( office.com ) 打开应用程序时,我也可以看到 SAML 请求。 (使用 chrome 扩展名 saml-chrome-panel)
尝试将 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>
更多细节,你可以参考这个article(translate to English)。
我在 Microsoft AzureAD 开了一张支持票。我从微软工程师那里得到了这个答案:
I have looked the issue you are having and the settings of the application.
You are setting Name ID as mail attribute and with e-mail format.
If I am understanding is wrong, please correct me.
In the case, if the user does not have value in mail attribute, then Azure AD would send persistent format for Name ID and set random value in it.
So please check if the user has value in its mail attribute.
真的!我测试的用户没有电子邮件属性!
根据微软支持人员的说法,他说从 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 return 在 SP 发起的流程中有什么价值。
看起来很像邮件值:user-email-address@foo.bar
原来当 mail 为 null 时,它将 return userPrincipalName
属性代替。
如果我们希望租户成员存在邮件属性,则该租户必须订阅邮件服务或捆绑包,如 Office 365、Exchange Online 等。在这种情况下,我们不订阅任何。我以为只需在 Azure 中创建一个用户,该用户就已经有电子邮件了!为了确定,我转到 outlook.com 并尝试登录。这是我得到的:
我正在使用 SAML 开发 SSO,我的 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
。
虽然我已经将 "name identifier format" 设置为 "Email address":
请注意,在 SP 启动的流程中,我可以通过指定 NameIDPolicy 让 Azure 发送电子邮件地址:
<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 响应并直接发送到 SP 的 ACS 端点。为什么还有SAML请求? (在 Azure 上测试应用程序时,我可以看到下载 SAML 请求的选项)。当我从应用程序面板 ( office.com ) 打开应用程序时,我也可以看到 SAML 请求。 (使用 chrome 扩展名 saml-chrome-panel)
尝试将 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>
更多细节,你可以参考这个article(translate to English)。
我在 Microsoft AzureAD 开了一张支持票。我从微软工程师那里得到了这个答案:
I have looked the issue you are having and the settings of the application. You are setting Name ID as mail attribute and with e-mail format. If I am understanding is wrong, please correct me.
In the case, if the user does not have value in mail attribute, then Azure AD would send persistent format for Name ID and set random value in it.
So please check if the user has value in its mail attribute.
真的!我测试的用户没有电子邮件属性! 根据微软支持人员的说法,他说从 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 return 在 SP 发起的流程中有什么价值。
看起来很像邮件值:user-email-address@foo.bar
原来当 mail 为 null 时,它将 return userPrincipalName
属性代替。
如果我们希望租户成员存在邮件属性,则该租户必须订阅邮件服务或捆绑包,如 Office 365、Exchange Online 等。在这种情况下,我们不订阅任何。我以为只需在 Azure 中创建一个用户,该用户就已经有电子邮件了!为了确定,我转到 outlook.com 并尝试登录。这是我得到的: