Enable use different identifier of role id and resource id in OAuth flow

[kratkyzobak]

Is your feature request related to a problem? Please describe.

If you want to create Azure AD application using IaC tools, you are stuck with need to define application roles before creating application itself. Current RabbitMQ implementation forces to name AppRoles by using ClientID in it. This value is not known before creating. For example terraform's azuread_application is unusable here.

If you change resource_server_id to string another than client-id you can prefix role names by this, but there is problem, that this ID is then appended in OAuth request as resource= so it's mandatory to be Client ID.

Describe the solution you'd like

I would propose to enable resource part from OAuth redirect query string in management plugin to differ from rabbitmq_auth_backend_oauth2.resource_server_id in https://github.com/rabbitmq/rabbitmq-server/blob/v3.11.13/deps/rabbitmq_management/src/rabbit_mgmt_wm_auth.erl#L41 for example by creating rabbitmq_management.oauth_resource_id which would default to rabbitmq_auth_backend_oauth2.resource_server_id.

Or alternatively I would propose to create switch which would lead to not excepting roles to be prefixed rabbitmq_management.oauth_resource_id at all.

Describe alternatives you've considered

There are workarounds requiring manual steps. Just do same as in click-ops mentoined in manual - in first step create app, fetch it's ID and then modify the app using this ID.

Additional context

No response

[michaelklishin]

The number of switches and alternative settings for various identity providers is already non-trivial.

I will defer to @MarcialRosales to decide whether we would accept a yet another one.

[kratkyzobak]

I belive, there should be some redesign of config options after major identity providers support is checked.

I would say, for example removing roles mandatory prefix would be nesscessary to lot of them.

There is also possibíity to just make solid JWT validation only and oauth for management can be let to any oauth proxy.

[michaelklishin]

@kratkyzobak thanks, we did "check" (produce examples for) a number of popular options. There are no plans for a significant redesign of the plugin, it has been constantly changing because the list of tools and scenarios to support is infinite and the number of people who would be willing to actively maintain the plugin is not.

Let's stick to one specific topic in this issue instead of general recommendations.

[MarcialRosales]

Hi @kratkyzobak, RabbitMQ scopes/roles must always be prefixed with the name of the resource_server_id not for the client_id. I understand your point which is that you want to declare roles/scopes regardless of the rabbitmq instance. Instead, you have to declare as many roles as rabbitmq instances.

But resource and resource_server_id and audience all refer to the same concept, the actual oauth2 name assigned to a particular rabbitmq cluster. oauth_client_id is completely separated from resource_server_id. If you want to declare your own scopes/roles, you can do it. Here it is explained.

[MarcialRosales]

@kratkyzobak We are considering the possibility of accepting the scopes without resource_server_id as prefix. Definitely it is less work for our users compared to having to declare scope aliases. Although there are users who prefer to use their custom scope and for that we still have the scope aliases functionality.

[kratkyzobak]

Yes, you're right. I have to use 2 AzureAD applications and it is then manageable through Terraform. Sorry I misread documentation, where single application example led me to try same approach.

You definitivelly can use separate application, where roles are defined and use it's application identifier as prefix of roles (both is user manageable in contrast of Client ID) and then one for SPA flow in management plugin.

For anyone, who will confuse self by trying to manage this by one application, keeping terraform resources to create AzureAD applications which can be then used as OAuth:

locals {
  # list of roles to create in application - see https://www.rabbitmq.com/oauth2.html#scope-and-tags
  rabbitmq_roles = {
    management = "tag:management"
    administrator = "tag:administrator"
    read_all = "read:*/*/*"
    write_all = "write:*/*/*"
    configure_all = "configure:*/*/*"
  }
  rabbitmq_unique_app_identifier = "api://rabbitmq-instanceidentifier"
  rabbitmq_mgmt_endpoint = "https://rabbit.example.com/"
}

resource "random_uuid" "rabbit_app_role" { for_each = local.rabbitmq_roles }
resource "random_uuid" "rabbit_app_scope" { } # not mandatory

# this application will have roles defined inside it
resource "azuread_application" "rabbit-api" {
   display_name = "RabbitMQ api for ${local.rabbitmq_unique_app_identifier}"
   api {
      mapped_claims_enabled          = true
      # this leads to audience is not app id guid, but string identifier
      requested_access_token_version = 1

      # not needed, but can be used to give Global consent to management application
     oauth2_permission_scope {
         id                         = random_uuid.rabbit_app_scope[0].id
        admin_consent_description  = "internal application"
        admin_consent_display_name = "RabbitMQ api for ${local.rabbitmq_unique_app_identifier}"
        enabled                    = true
        type                       = "User"
        user_consent_description   = "internal applicatiin"
        user_consent_display_name  = "RabbitMQ api for ${local.rabbitmq_unique_app_identifier}"
        value                      = "not-important"
      }
   }
   
   # important
   identifier_uris = [local.rabbitmq_unique_app_identifier]

  dynamic "app_role" {
    for_each = local.rabbitmq_roles
    content {
      id                   = random_uuid.rabbit_app_role[app_role.key].id
      allowed_member_types = ["User", "Application"] # if you plan only Mgmt plugin access use only ["User"] here
      # important - has to be prefixed by app identifier
      value                = "${local.rabbitmq_unique_app_identifier}.${app_role.value}"
      display_name         = app_role.key
      description          = "Access to the RabbtiMQ with given role"
      enabled              = true
    }
  }
}

resource "azuread_service_principal" "rabbit-api" {
  application_id = azuread_application.rabbit-api.application_id
  use_existing = true
}

resource "azuread_application" "rabbit-mgmt" {
   display_name = "RabbitMQ management SPA for ${local.rabbitmq_unique_app_identifier}"
  single_page_application {
    redirect_uris = ["https://${local.rabbitmq_mgmt_endpoint }js/oidc-oauth/login-callback.html"]
  }

  required_resource_access {
    resource_app_id = "00000003-0000-0000-c000-000000000000"    
    resource_access {
      id   = "14dad69e-099b-42c9-810b-d002981feec1" # MicrosoftGraph -> User.Read to include user name in token
      type = "Scope"
    }
  }

  # to enable this APP request tokens for roles of Rabit. You can skip some roles here if you want (and you will not have them in access token even )
  required_resource_access { 
    resource_app_id = azuread_application.rabbit-api.application_id
    dynamic "resource_access" {
        for_each = local.rabbitmq_roles 
       content {
          id   = random_uuid.rabbit_app_role[resource_access.key].id
         type = "Role"
       }
    }
  }
}

# Assign roles to some superuser (not needed - to test assign to yourself)
resource "azuread_app_role_assignment" "rabbit_management_api_superuser" {
  for_each = local.rabbitmq_roles 
  app_role_id         = random_uuid.rabbit_app_role[each.key].id
  principal_object_id = "Some-Administrator-Uid"
  resource_object_id  = azuread_service_principal.rabbit-api.object_id
}

# not important - does "Grant admin consent" for mgmt SPA -> API app so users would not need consent each one
resource "azuread_application_pre_authorized" "rabbit_allow_spa_to_request_token" {
  application_object_id = azuread_application.rabbit-api.object_id
  authorized_app_id     = azuread_application.rabbit-mgmt[0].application_id
  permission_ids        = [random_uuid.rabbit_app_scope.id]
}

And according config then:

auth_backends.1 = rabbit_auth_backend_oauth2
management.oauth_enabled = true
management.oauth_client_id = ${azuread_application.rabbit-mgmt.application_id}
management.oauth_provider_url = "https://login.microsoftonline.com/${var.tenant_id}"
auth_oauth2.resource_server_id = ${local.rabbitmq_unique_app_identifier}
auth_oauth2.additional_scopes_key = "roles"
auth_oauth2.jwks_url = "https://login.microsoftonline.com/${var.tenant_id}/discovery/v2.0/keys"

[MarcialRosales]

So you are back in business, arent you? Am I right to say that your terraform configuration would be simpler if you did not have to prefix the rabbitmq's scopes? Not massively simpler but just a bit.

[kratkyzobak]

@MarcialRosales - I will stay with 2 AzureAD applications as it's better to decouple them for us (we will use also other applications to gain tokens)

Currently only one problem with prefixing is needing to request older Azure AD tokens versions (Access tokens v1 contains "app uri" in aud field, but v2 contains client id here) - problem when resource, audience and roles prefix has to be equal. But v1 tokens are not deprecated now so using them is not blocking us from switching to OIDC authorization to RabbitMQ.

So currently this issue is not blocker for us but nice to have.

And yes - I agree, that prefixing can be good for some scenarios with different IdPs and it's optionality was my suggestion.

[MarcialRosales]

@kratkyzobak This PR should make your deployment simpler. If you want to try it out, here is the docker image: pivotalrabbitmq/rabbitmq:configurable-oauth2-scope-prefix-otp-min-bazel