OAuth 2: Variable expansion in resource permissions

[inseroaj]

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

As described in OAuth2 Topic Exchange Scopes it is possible to use variable expansion in scopes, like rabbitmq.write:*/x-{vhost}-*.
However, it seems this is not working/supported in Scope Aliases.
Addition of this feature would make it easy to apply user-based permissions with a single fixed scope.

Describe the solution you'd like

Consider a token including the scope MYSCOPE.
Using a scope alias, the read permission can be set with
auth_oauth2.scope_aliases.MYSCOPE = rabbitmq.read:*/queueprefix.{sub}.*
This would cause a user with subject MYUSER and scope MYSCOPE to have read access to queues named queueprefix.MYUSER.*.

Describe alternatives you've considered

No response

Additional context

No response

[MarcialRosales]

@inseroaj Indeed, this feature was initially added exclusively when checking permission on topics as it is stated in the docs.
In your description of this issue, you used the scope rabbitmq.write:*/x-{vhost}-*. as an example of variable expansion. However. this example will not work because it is not a topic exchange permission. If you look at the docs, you will see that all the examples includes a routing key part. This is an example

{
  "sub" : "bob",
  "scope" : [ "rabbitmq.write:*/x-{vhost}-*/u-{sub}-*" ]
}

Your example is a normal resource permission which is made up of a vhost part and a resource part separated by /.

Scope aliases does not evaluate permissions, it only maps a word into one or many scopes.

Having said all the above, I am going to work on supporting variable expansion in resource permissions so that rabbitmq.write:*/x-{vhost}-*. works regardless whether the scope came in a token or from a scope alias translation.

[inseroaj]

Thanks for your reply. I'm still not sure I understand exactly how this works.
I tried setting the scope rabbitmq.read:*/queueprefix.{name}.*/*, and then using AMQP 1.0 connecting to address /queues/queueprefix.MYUSER.somequeue, but get the error read access to queue 'queueprefix.MYUSER.somequeue' in vhost '/' refused for user 'MYUSER'.
Is this expected, and how can I get this to work?

And assuming a working example, should this also work specifying the same scope with {name} variable in a scope alias ?

[MarcialRosales]

@inseroaj does your token contain a claim with the name name? Because RabbitMQ will use any claim in the token plus the variable name vhost, which is the vhost being requested. If you intend to use a username, you have to configure which claim exactly contains the username.

[inseroaj]

@MarcialRosales Yes, the token includes these claims:
"name": "MYUSER"
"permissions": "rabbitmq.read:*/queueprefix.{name}.*/*"
and the rabbitmq.conf contains
auth_oauth2.additional_scopes_key = permissions.

Using
"permissions": "rabbitmq.read:*/queueprefix.MYUSER.*/*"
works as expected

[michaelklishin]

@inseroaj our team does not use issues for discussions. Use Discussions if you have questions.

[MarcialRosales]

@inseroaj I am updating the oauth2 examples to demonstrate "var expansion feature ". However, while I do it, I can advance what it looks like :

1. I use this setup https://www.rabbitmq.com/docs/oauth2-examples-keycloak
2. I go to the keycloak administration console, and I declare a client scope rabbitmq.configure:*/q-{user_name}
3. I grant this client scope to the client used by the management ui in this setup, called rabbitmq-client-code
4. I log in with the user rabbit_admin
5. I get an access token like this

{
  "exp": 1749568914,
  "iat": 1749568614,
  "auth_time": 1749568614,
  "jti": "943e4178-0511-4374-bc9e-8e7733b09273",
  "iss": "https://keycloak:8443/realms/test",
  "aud": "rabbitmq",
  "sub": "22501eae-7576-4749-86c2-0d593212a56a",
  "typ": "Bearer",
  "azp": "rabbitmq-client-code",
  "session_state": "9ca3ef92-5103-422e-9b5d-6a330941e002",
  "acr": "1",
  "allowed-origins": [
    "http://localhost:15672"
  ],
  "realm_access": {
    "roles": [
      "default-roles-test",
      "rabbitmq.tag:administrator",
      "offline_access",
      "test-var-expansion",
      "uma_authorization"
    ]
  },
  "resource_access": {
    "account": {
      "roles": [
        "manage-account",
        "manage-account-links",
        "view-profile"
      ]
    }
  },
  "scope": "openid profile email rabbitmq.tag:administrator rabbitmq.configure:*/q-{user_name}",
  "sid": "9ca3ef92-5103-422e-9b5d-6a330941e002",
  "email_verified": true,
  "user_name": "rabbit_admin",
  "preferred_username": "rabbit_admin",
  "given_name": "",
  "family_name": "",
  "email": "marcialfrg@hotmail.com",
  "extra_scope": [
    "default-roles-test",
    "rabbitmq.tag:administrator",
    "offline_access",
    "test-var-expansion",
    "uma_authorization"
  ]
}

6. As expected, when I create a queue called test , it fails
7. And as expected, when i create a queue called q-rabbit_admin .. it works meaning that RabbitMQ resolved the var user_name

Please, be aware that I have updated the file under the rabbitmq-oauth2-tutorial repo, main branch, the file bin//deploy-rabbit so that it uses 4.1.1 release of RabbitMQ.

IMAGE_TAG=${IMAGE_TAG:-4.1.1-management}

When I finish adding the example that demonstrates the feature "variable expansion in scopes", I will push this change too that bumps up the RabbitMQ version used by the examples.