feat: Expose service principal id of a the inplicit crated sp when using aad/entra id applications

[hegerdes]

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

Description

Consider the following use case: You crate a AAD/EntraID App Registration used for OIDC authentication. This app shoude manage some azure resources such as a KeyVault. You need a service principle and a role assessment for that app/sp to access the KeyVault. But currently you cant get the implicent created service principle of an ad_app. You have to add an extra data source. See example.

It would be much nicer to get the implicit created SP ID of the app directly via the azuread_application ressource and not having to go the extra route over the azuread_service_principal data source.

New or Affected Resource(s)

• azuread_application

Potential Terraform Configuration

data "azuread_client_config" "current" {}
data "azurerm_subscription" "example" {}

resource "azuread_application" "gh-actions" {
  display_name     = "aad-gh-actions"
  owners           = [data.azuread_client_config.current.object_id]
  sign_in_audience = "AzureADandPersonalMicrosoftAccount"

  api {
    mapped_claims_enabled          = true
    requested_access_token_version = 2
  }
  required_resource_access {
    resource_app_id = "00000003-0000-0000-c000-000000000000"

    resource_access {
      id   = "18a4783c-866b-4cc7-a460-3d5e5662c884"
      type = "Role"
    }
  }

}

data "azuread_service_principal" "gh-actions" {
  client_id = azuread_application.gh-actions.client_id
}

resource "azurerm_role_assignment" "sub-example-reader-aad-gh" {
  scope                = data.azurerm_subscription.example.id
  role_definition_name = "Reader"
  principal_id         = data.azuread_service_principal.gh-actions.id
}

References

[nbaju1]

Not all application registrations necessarily have an associated service principal. If you need a service principal from an application registration, you should define that as a resource in your Terraform config, i.e.:

data "azuread_client_config" "current" {}
data "azurerm_subscription" "example" {}

resource "azuread_application" "gh-actions" {
  display_name     = "aad-gh-actions"
  owners           = [data.azuread_client_config.current.object_id]
  sign_in_audience = "AzureADandPersonalMicrosoftAccount"

  api {
    mapped_claims_enabled          = true
    requested_access_token_version = 2
  }
  required_resource_access {
    resource_app_id = "00000003-0000-0000-c000-000000000000"

    resource_access {
      id   = "18a4783c-866b-4cc7-a460-3d5e5662c884"
      type = "Role"
    }
  }

}

resource "azuread_service_principal" "gh-actions" {
  client_id = azuread_application.gh-actions.client_id
}

resource "azurerm_role_assignment" "sub-example-reader-aad-gh" {
  scope                = data.azurerm_subscription.example.id
  role_definition_name = "Reader"
  principal_id         = azuread_service_principal.gh-actions.id
}

[manicminer]

Thanks for opening this issue @hegerdes. Whilst a service principal in the current tenant is created implicitly when registering applications in the portal, a service principal is not automatically created when using an azuread_application or an azuread_application_registration resource. As @nbaju1 says, you would need to explicitly create one using the azuread_service_principal resource.

This behavior is by design both on the part of the API and the provider. An application can have zero or more service principals, across any number of tenants. For this reason it's not practical to expose any attributes for the service principal on the azuread_application / azuread_application_registration resource. It is left to the practitioner to decide on the configuration needed for their use case. For a majority of single-tenant applications, this will involve the application plus a service principal in the same tenant.

I hope this helps clear up any confusion about this topology - there is an excellent article on the Microsoft site that goes into more detail on how this all works under the hood.

Since this is more of a design/usage question, I'm going to close this issue for now. I recommend checking out the Azure providers Slack community where you can get help from other users and maintainers, details are in the project readme.