AzureAD IDP Initiated SAML always return nameid-format:persistent instead of nameid-format:emailAddress

Question

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

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>

This is what I'm expected:

<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
    [email protected]
</NameID>

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

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>

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>

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

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)

Answer 1

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

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.

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:

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.

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

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

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:

Answer 2

I am wondering if you know where in your Azure configuration the programming existed to tell the SAML authentication to default the nameid to persistent when mail was null. Can you tell me that? I'm having a similar but slightly different issue. SAML assertion shows correct nameid via SP and IDP initiated links to desktop site, and users successfully authenticate. However, users fail authentication to mobile app, which is designed to authenticate via the same SAML2 setup. SAML assertion logs reflect a different nameid value, which can't be validated against the vendor site. We can't determine where the secondary nameid value is coming from in Azure, as there is only one are in the attributes for the Unique User Identifier.
Would love some direction! Thanks!