OAuth 2: support multiple resources, extract an OAuth 2 client

[MarcialRosales]

Proposed Changes

Merge PR oauth-multi-resource-support and create-oauth2-client

What

This PR adds the following OAuth 2.0 capabilities/features:

• A single RabbitMQ cluster can declare more than one oauth 2.0 resource. Prior to this PR, you could only declare one resource, via resource_server_id setting. This was more than sufficient for most setups. However, there are environments where one RabbitMQ cluster is referenced by more than one "tenant" and each "tenant" refers to RabbitMQ with a different resource's name/id.
• In addition to supporting more than one resource, each resource may be "managed" by a different Identity Provider. In other words, users (or oauth clients used by messaging apps) may be registered in different providers and therefore their tokens are signed using different signing keys. With this PR it is now possible to configure one Oauth provider for all resources, or one OAuthProvider per resource.
• When RabbitMQ has been configured with more than one resource, the Management UI prompts the user to choose which resource to log in with. If there is only one resource, RabbitMQ does not need to ask anything, instead the user only has to click on the button "Click here to login". When there is more than one resource, the user chooses from a list of available resources and clicks on the same button as before.
• Prior to this PR, it was not possible to enable basic authentication along with OAuth2 authentication. They were mutually exclusive. Now, if management.oauth_disable_basic_auth is false and management.oauth_enabled is true, the user is presented with two sections, one for Oauth2 and another for Basic Auth. And the user ultimately clicks the appropriate button to login.
• In the majority of RabbitMQ deployments with OAuth 2.0 authentication, there is only one OAuth2 server and that server is OpenID compliant. Therefore, users should not need to figure out what is the JWKS_URL of their Identity provider and set it up on auth_oauth2.jwks_url. Instead, RabbitMQ should be able to contact the OpenId Configuration endpoint and figure out the jwks_uri. This PR does exactly that. Now, users only need to configure the root url of their identity provider in a new setting called auth_oauth2.issuer. And RabbitMQ discovers the jwks_uri (among other endpoints) and from it, it downloads the signing keys. Furthermore, users do not need to configure management.oauth_provider_url because this url is typically the issuer url. That is the url where to redirect users to authenticate and get a token. If that url did not coincide with the issuer url (which would be very odd), users can configure management.oauth_provider_url.

Acceptance Tests

About RabbitMQ docker image used to run the tests

The acceptance tests use a RabbitMQ docker image built from this PR. Here is where the default image is set.
However, if you want to run these acceptance tests against an image built locally from this PR, you can override the IMAGE and IMAGE_TAG this way: This command deploys RabbitMQ using the image and image tag specified and it uses the rabbitmq.conf file found under conf/keycloak folder.

IMAGE="bazel/packaging/docker-image" IMAGE_TAG="rabbitmq" MODE=keycloak make start-rabbitmq

Test 1 - It is possible to configure two OAuth resources and users and clients who access these two resources are registered on the same OAuth provider but under two separate tenant (a.k.a. realms).

1. Go to https://github.com/rabbitmq/rabbitmq-oauth2-tutorial/blob/support-multiple-resource-server-ids/use-cases/multiresource.md
2. Follow the instructions in the prerequisites section
3. Follow the instructions in the Scenario 2
   . This scenario explains step by step how to bootstrap keycloak(s) instances, RabbitMQ (it also says which configuration file is used) and finally how to test various flows: amqp, management rest api, management ui with two users thru two different resources

Test 2 - Same as in the previous scenario but now each resource is physically managed by two separate servers.

1. Go to https://github.com/rabbitmq/rabbitmq-oauth2-tutorial/blob/support-multiple-resource-server-ids/use-cases/multiresource.md
2. Follow the instructions in the prerequisites section
3. Follow the instructions in the Scenario 3

Test 3 - It is possible to combine oauth2 authentication with more than one resource and basic authentication in the management ui

1. Edit the rabbitmq.scenario2.conf configuration file used in Test 1 abvove. And add the following lines :

auth_backends.2 = rabbit_auth_backend_internal
management.oauth_disable_basic_auth = false

3. Start RabbitMQ as per instructions in Test 1
4. Go to http://localhost:15671
5. Make sure there are two sections:

• OAuth 2.0
• Basic Authentication with username and password form

6. Login as guest:guest