【问题标题】:AzureAD IDP Initiated SAML always return nameid-format:persistent instead of nameid-format:emailAddressAzureAD IDP 发起的 SAML 始终返回 nameid-format:persistent 而不是 nameid-format:emailAddress
【发布时间】:2023-03-31 18:54:01
【问题描述】:

我正在使用 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。 虽然我已将“名称标识符格式”设置为“电子邮件地址”:

请注意,在 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)

【问题讨论】:

    标签: azure azure-active-directory saml saml-2.0 idp


    【解决方案1】:

    尝试使用带有NameIDPolicy 的 IdP 启动流

    <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(翻译成英文)。

    【讨论】:

    • 我相信我无法控制,因为 IdP 确实创建了 SAML 请求。作为 SP 发起的流程,我添加了 NameIDPolicy 并且我得到了我想要的正确的 nameid 类型。 “尝试使用带有 NameIDPolicy 的 IdP 发起的流程”是什么意思?
    • Azure AD currently supports the following NameID Format URI for SAML 2.0:urn:oasis:names:tc:SAML:2.0:nameid-format:persistent. 使用时使用SAML 2.0 idp flow
    【解决方案2】:

    我在 Microsoft AzureAD 上开了一张支持票。我从微软工程师那里得到了这个答案:

    我查看了您遇到的问题以及应用程序的设置。 您正在将名称 ID 设置为邮件属性并使用电子邮件格式。 如果我理解有误,请纠正我。

    在这种情况下,如果用户在邮件属性中没有值,则 Azure AD 将发送持久格式的名称 ID 并在其中设置随机值。

    所以请检查用户的邮件属性是否有值。

    真的!我测试的用户没有电子邮件属性! 根据微软支持人员的说法,他说从 Azure Portal,我们无法判断被测试的租户成员是否有电子邮件:

    他说我们可以使用 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属性。

    如果我们希望租户成员存在属性邮件,则该租户必须订阅邮件服务或 Office 365、Exchange Online 等捆绑包。在这种情况下,我们不订阅任何内容。我以为只需在 Azure 中创建一个用户,并且该用户已经有一封电子邮件!只是为了确保,我去outlook.com 并尝试登录。这是我得到的:

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2012-04-23
      • 2014-12-05
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2015-08-09
      相关资源
      最近更新 更多