azuread_application resource doesn't appear to set NameId SAML attribute correctly

[dcopestake]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritise this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritise the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform (and AzureAD Provider) Version

Terraform v1.2.5
on windows_386

• provider registry.terraform.io/hashicorp/aws v4.16.0
• provider registry.terraform.io/hashicorp/azuread v2.26.1

Affected Resource(s)

• azuread_application
• azuread_service_principal

Terraform Configuration Files

resource "random_uuid" "role_ids" {
  for_each = local.exposed_roles
}

resource "azuread_application" "opensearch" {
  display_name = local.opensearch_fqdn

  owners = [
    data.azuread_client_config.current.object_id,
  ]

  identifier_uris = [
    local.opensearch_domain_url,
  ]

  web {
    implicit_grant {
      access_token_issuance_enabled = false
      id_token_issuance_enabled     = true
    }

    homepage_url = local.opensearch_domain_url
    logout_url   = "${local.opensearch_domain_saml_url}/logout"

    redirect_uris = [
      "${local.opensearch_domain_saml_url}/acs",
    ]
  }

  dynamic "app_role" {
    for_each = local.exposed_roles

    content {
      id = random_uuid.role_ids[app_role.key].id

      allowed_member_types = [
        "User",
      ]

      display_name = app_role.value.id
      description  = app_role.value.description
      value        = app_role.value.id
    }
  }
}

resource "azuread_service_principal" "opensearch" {
  application_id = azuread_application.opensearch.application_id

  owners = [
    data.azuread_client_config.current.object_id,
  ]

  app_role_assignment_required = true

  feature_tags {
    custom_single_sign_on = true
    enterprise            = true
    hide                  = !var.show_azure_enterprise_app
  }

  preferred_single_sign_on_mode = "saml"
}

Expected Behavior

When creating a azuread_application resource and configuring for SAML I'm expecting the NameId attribute to be mapped properly and return something like the following during the auth flow:

<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">my.obfuscated.email@address.com</NameID>

And then show in the Service Provider (an OpenSearch domain in this case) to see the user's user id as my.obfuscated.email@address.com.

Actual Behavior

After authenticating each user's user id is not set correctly. From the SAML response I can see:

<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">KoIbJEiimY6YA-xyPZ02iBpQX2h3gug5VX7F-HP5Dus</NameID>

And in the Service Provider I see the user's user id as KoIbJEiimY6YA-xyPZ02iBpQX2h3gug5VX7F-HP5Dus.

Steps to Reproduce

1. terraform apply

Important Factoids

If I look at the "Attributes & Claims" under SAML Single Sign-on in the Azure console everything looks correct, and the Unique User Identifier (Name ID) claim is set to user.userprincipalname [nameid-format:emailAddress] as I'd expect, but that behaviour doesn't actually appear to be being applied.

What's even more strange, is that if I change the Unique User Identifier (Name ID) to something else random and then back to user.userprincipalname [nameid-format:emailAddress] - all via the Azure console - things start working! So it almost looks like this isn't being initialised when creating the resource via Terraform, but it does when done via the Azure console.

[manicminer]

Hi @dcopestake, thanks for reporting and for the detailed repro information. At this time we do not have any control over these SAML related settings, as the API does not expose them. Unfortunately this means that only the portal (and potentially other first-party applications like Azure CLI or Az pwsh module) are able to configure these SAML settings. Additionally, whatever defaults are set as a result of this disparity, are also out of our control.

As soon as we have API support for these settings, we will be happy to support them.

Related: #173

[firesock]

As a quick workaround just to get the correct NameID into the SAML, we managed to make it work using a claims mapping policy:

resource "azuread_claims_mapping_policy" "saml_nameid_fix" {
  display_name = "SAML NameID Fix"

  definition = [
    jsonencode(
      {
        ClaimsMappingPolicy = {
          ClaimsSchema = [
            {
              ID               = "userprincipalname"
              SamlClaimType    = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
              SamlNameIdFormat = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
              Source           = "user"
            }
          ]
          IncludeBasicClaimSet = "true"
          Version              = 1
        }
      }
    ),
  ]
}

resource "azuread_service_principal_claims_mapping_policy_assignment" "saml_nameid_fix" {
  claims_mapping_policy_id = azuread_claims_mapping_policy.saml_nameid_fix.id
  service_principal_id     = azuread_service_principal.MY_SERVICE_PRINCIPAL.id
}

Taken from https://learn.microsoft.com/en-us/answers/questions/866963/update-saml-nameid-format-using-ms-graph

Note that the Azure console currently also adds a http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress from user.mail attribute which doesn't seem to be included in IncludeBasicClaimSet but can be added to this claims mapping policy as well.

[niwic]

We had the same problem as OP except we created the resources manually thorough the Azure web user interface. The field Name identifier format was "Email address" as it should, but the SAML Assertion returned <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">[...]</NameID>. We managed to fix it the same way as OP too. We changed the provider to something else, and then back to "Email address" and we started getting the correct NameID in the Assertion.

I'm adding a commend about our experience here, as I could not find this issue reported anywhere else.