我正在使用 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">
[email protected]
</NameID>
我总是得到nameid-format:persistent
而不是nameid-format:emailAddress
。尽管我已将“名称标识符格式”设置为“电子邮件地址”:
请注意,在 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)
答案1
我在 Microsoft AzureAD 上开了一个支持单。我得到了微软工程师的答复:
我查看了您遇到的问题和应用程序的设置。您将名称 ID 设置为邮件属性,并采用电子邮件格式。如果我的理解有误,请纠正我。
在这种情况下,如果用户的邮件属性中没有值,则 Azure AD 将发送名称 ID 的持久格式并在其中设置随机值。
因此,请检查用户的邮件属性是否有值。
真的!我测试的用户没有电子邮件属性!根据微软支持人员的说法,他表示从 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 发起的流程中返回什么值。它看起来很像邮件值:[email protected]
事实证明,当邮件为空时,它将返回userPrincipalName
属性。
如果我们希望租户成员具有邮件属性,则该租户必须订阅邮件服务或捆绑包,如 Office 365、Exchange Online 等。在这种情况下,我们不订阅任何服务。我以为只需在 Azure 中创建一个用户,该用户就已经有电子邮件了!为了确保万无一失,我去了 outlook.com 并尝试登录。这是我得到的:
答案2
我想知道您是否知道在 Azure 配置中存在编程来告诉 SAML 身份验证在邮件为空时将 nameid 默认为持久。您能告诉我吗?我遇到了类似但略有不同的问题。SAML 断言通过 SP 和 IDP 发起的桌面站点链接显示正确的 nameid,并且用户成功验证。但是,用户无法通过移动应用程序的身份验证,该应用程序旨在通过相同的 SAML2 设置进行身份验证。SAML 断言日志反映了不同的 nameid 值,无法根据供应商站点进行验证。我们无法确定 Azure 中的辅助 nameid 值来自哪里,因为唯一用户标识符的属性中只有一个。
希望得到一些指导!谢谢!