Reintroduce `azuread_application_app_role`

[tomaciazek]

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

Please reintroduce the azuread_application_app_role resource. I see that this functionality is already implemented in the azuread_application in its new, robust form in v2.0, but removing it removes the ability to create application roles independently from the application.

A concrete use-case: creating roles used to managed access through SSO. Only one application can govern an SSO binding and let's say it is managed by a separate TF configuration or outside Terraform entirely. What I'm trying to do is to create roles (on the application that is used for SSO) in multiple other configurations that are managed independently.

New or Affected Resource(s)

• azuread_application_app_role

Potential Terraform Configuration

resource "azuread_application" "example" {
  name = "example"
}

resource "azuread_application_app_role" "example" {
  application_object_id = azuread_application.example.id
  allowed_member_types  = ["User"]
  description           = "Admins can manage roles and perform all task actions"
  display_name          = "Admin"
  enabled               = true
  value                 = "administer"
}

References

• 465

[manicminer]

Hi @tomaciazek, thanks for requesting this. For background, at the time we removed the azuread_application_app_role resource, this was to resolve some other bugs which occurred at the unfortunate confluence of API semantics and limitations in Terraform. In the near future, it's possible these Terraform limitations may be able to be lifted, but it's not clear right now and requires further investigation.

As such, I'm happy to keep this feature request open, but just to set expectations, it's not yet guaranteed whether we'll be able to confidently reintroduce virtual resources like this one without breaking backwards compatibility with pre-1.0 versions of Terraform.

[sce81]

just to put my own 2p into this. i need to integrate into a customers existing application. The only way for me to utilise app role functionality would be to import the customers entire application into terraform (i don't have the required permissions to do this) or to recreate the application in terraform (i don't have the budget for this) or to use remote/local_exec which is absolute last resort IMO. I can create app roles within their own sub section of the AzureAD Console. This seems a fairly critical component to not be able to utilise.

[timothyclarke]

I'd like this to extend to azuread_application_oauth2_permission. Managing the entire app as one monolithic thing makes the code quite large and brittle.

When adding app_roles using a dynamic block with groups to map onto those roles (so we can assign the permissions to people in a RBAC way). Resource targeting is needed to force the update of the application otherwise everything breaks eg

resource "azuread_application" "example" {
  name = "example"
  dynamic "app_role" {
    for_each = { for role in var.app_roles : role.value => role }
    content {
      ...
    }
  }
}

resource "azuread_service_principal" "example" {
  application_id = azuread_application.example.application_id
}

resource "azuread_group" "example" {
  for_each = { for role in var.app_roles : role.value => role }

  display_name     = format("%s %s", var.group_name_prefix, each.key)
  owners           = [data.azuread_client_config.current.object_id]
  security_enabled = true
}

resource "azuread_app_role_assignment" "example" {
  for_each = { for role in var.app_roles : role.value => role }

  app_role_id         = azuread_service_principal.example.app_role_ids[each.key]
  principal_object_id = azuread_group.example[each.key].object_id
  resource_object_id  = azuread_service_principal.example.object_id
}

[wiebeck]

Also I think having virtual resourcese for app roles allows for circular resource access configuration, e.g. App A defines app role A1 and has required resoure access on app role B1 of app B which itself has required resource access on app role A1 of app A. Or is there another way working around this?

[jrblanno]

hi! This would be amazing, any news?

[michelefa1988]

@manicminer any update about this? In order to setup oauth2 for rabbitmq, one requires the approle value to be set to the application_id, something which cannot be done if the azuread_application_app_role is part of the application (circular reference)

Any idea when this functionality will be released?

[penenkel]

I think this has been completed with #1214