AzureAD IDP启动的SAML始终返回nameid-format:persistent而不是nameid-format:emailAddress [英] AzureAD IDP Initiated SAML always return nameid-format:persistent instead of nameid-format:emailAddress

问题描述

我正在使用SAML开发SSO，而我的IdP是Azure.

I'm developing SSO using SAML and my IdP is Azure.

IDP发起的流程有问题.在SAML响应中，我总是得到此NameID:

I'm having problem with IDP Initiated flow. In SAML Response I always get this 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">
    [e-mail]
</NameID>

我总是得到 nameid-format:persistent 而不是 nameid-format:emailAddress .尽管我已将名称标识符格式"设置为电子邮件地址":

I always get nameid-format:persistent instead of nameid-format:emailAddress. Although I have set "name identifier format" to be "Email address":

请注意，在SP发起的流程上，我可以通过指定NameIDPolicy来让Azure发送电子邮件地址:

Notice that on SP Initiated flow, I could get Azure to send email Address by specifying 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

However on IdP Initiated flow, the AuthnRequest doesnot have 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应用程序配置是否不正确.

I'm wondering whether my Azure app configuration has something not right.

通过关于IdP发起流的方式，我认为IdP将创建SAML响应并直接发送到SP的ACS端点.为什么仍然存在SAML请求?(在Azure上测试应用程序时，我会看到下载SAML请求的选项).从应用程序面板(office.com)打开应用程序时，我也可以看到SAML请求.(使用Chrome扩展名saml-chrome-panel)

By the way about IdP Initiated Flow, I thought that IdP will create SAML Response and send straight to SP's ACS endpoint. Why there is still SAML request? (When test the app on Azure I could see options to download SAML request). When I open the app from the application panel ( office.com ), I could see SAML request too. (using chrome extension saml-chrome-panel)

推荐答案

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

I opened a support ticket at Microsoft AzureAD. I got this answer from Microsoft engineer:

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

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.

在这种情况下，如果用户在mail属性中没有值，则Azure AD将发送持久格式的Name ID并在其中设置随机值.

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.

真的！我测试的用户没有电子邮件属性！根据Microsoft支持人员的说法，他说从Azure门户网站，我们无法确定受测租户成员是否有电子邮件:

Really! My tested user doesn't have email attribute! According to Microsoft support guy, he said that from Azure Portal, we can't tell that the tested tenant member has email or not:

他说我们可以使用PowerShell或Azure CLI进行测试:

He said that we can test using PowerShell or 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": ....
}

被测试的用户没有邮件属性.因此，行为是预期的.

The tested user doesn't have mail attribute. So the behavior is expected.

但是我仍然想知道IdP在SP发起的流中返回什么值.它看起来真的像邮件值: [e-mail]

But I'm still wondering what value does IdP return in SP Initiated flow. It look really like mail value: [e-mail]

结果证明，当mail为null时，它将返回 userPrincipalName 属性.

Turn out that when mail is null, it will return userPrincipalName attribute instead.

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

If we want tenant member to exist attribute mail, that tenant must subscribe to a mail service or a bundle package like Office 365, Exchange Online, etc. In this case we don't subscribe to any. I thought that just create an user in Azure and that user already has a email! Just to make sure, I go to outlook.com and try to login. This is what I got:

这篇关于AzureAD IDP启动的SAML始终返回nameid-format:persistent而不是nameid-format:emailAddress的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！