You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/management/index.md
-4Lines changed: 0 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -410,10 +410,6 @@ Given above configuration, when a user visits the management UI, the following t
410
410
If RabbitMQ cannot download the OpenID provider configuration, it shows an error message and OAuth 2.0 authentication is disabled in the management UI.
411
411
:::
412
412
413
-
:::tip
414
-
If you used to configure `auth_oauth2.metadata_url` because your provider did not use the standard path OpenId Discovery endpoint's path, since RabbitMQ 4.1 you should instead configure the correct path and/or include any additional parameters as it is explained [here](./oauth2#discovery-endpoint-params).
415
-
:::
416
-
417
413
2. RabbitMQ displays a button with the label "Click here to login". When the user clicks on the button, the management UI initiates the OAuth 2.0 Authorization Code Flow, which redirects the user to the identity provider to authenticate and get a token.
Copy file name to clipboardExpand all lines: docs/oauth2-examples-multiresource.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -43,7 +43,7 @@ different OAuth2 servers or they could be registered on the same OAuth2 server h
43
43
## AMQP clients and management users registered in same OAuth 2.0 server but with different audience
44
44
45
45
RabbitMQ is configured with two OAuth2 resources one called `rabbit_prod` and another `rabbit_dev`. For example purposes, let's say, the production team refer to RabbitMQ with the `rabbit_prod` audience. And the development team with the `rabbit_dev` audience.
46
-
As both teams are registered in the same OAuth2 server you are going to configure its settings such as `jwks_url` at the
46
+
As both teams are registered in the same OAuth2 server you are going to configure its settings such as `jwks_uri` at the
47
47
root level so that both resources share the same configuration.
48
48
49
49
In the past, RabbitMQ imposed a restriction where the scopes had to be prefixed with the name of the resource/audience. For instance, if `resource_server_id` was `rabbitmq1`, all scopes had to be prefixed with the value `rabbitmq1`, for example `rabbitmq1.tag:administrator`.
Copy file name to clipboardExpand all lines: docs/oauth2.md
+12-12Lines changed: 12 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -152,9 +152,9 @@ In chronological order, here is the sequence of events that occur when a client
152
152
| `auth_oauth2.issuer` | The [issuer URL](#configure-issuer) of the authorization server. It is used to build the discovery endpoint url to discover other endpoints such as such as `jwks_uri`. And this issuer URL is also the URL where to send RabbitMQ management users to login and get a token.
153
153
| `auth_oauth2.discovery_endpoint_path` | The path used for the [OpenId discovery endpoint](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata). The endpoint URI is built using `auth_oauth2.issuer`, this path or else the default path `.well-known/openid-configuration` followed by query parameters configured in the following variable
154
154
| `auth_oauth2.discovery_endpoint_params` | [List of HTTP query parameters](#discovery-endpoint-params) sent to the OpenId discovery endpoint.
155
-
| `auth_oauth2.jwks_url` | The URL of the [JWKS endpoint](#jwks-endpoint). According to the [JWT Specification](https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.2), the endpoint URL must be https. Optional if you set `auth_oauth2.issuer`. If this URL is set, it overrides the `jwks_uri` discovered via the discovery endpoint.
155
+
| `auth_oauth2.jwks_uri` | The URL of the [JWKS endpoint](#jwks-endpoint). According to the [JWT Specification](https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.2), the endpoint URL must be https. Optional if you set `auth_oauth2.issuer`. If this URL is set, it overrides the `jwks_uri` discovered via the discovery endpoint.
156
156
| `auth_oauth2.token_endpoint` | The URL of the OAuth 2.0 token endpoint. Optional if you set `auth_oauth2.issuer`. If this URL is set, it overrides the `token_endpoint` discovered via the discovery endpoint.
157
-
| `auth_oauth2.https.cacertfile` | Path to a file containing PEM-encoded CA certificates. The CA certificates are used to connect to any of these endpoints: `jwks_url`, `token_endpoint`, or the discovery endpoint.
157
+
| `auth_oauth2.https.cacertfile` | Path to a file containing PEM-encoded CA certificates. The CA certificates are used to connect to any of these endpoints: `jwks_uri`, `token_endpoint`, or the discovery endpoint.
158
158
| `auth_oauth2.https.depth` | The maximum number of non-self-issued intermediate certificates that may follow the peer certificate in a valid [certification path](ssl#peer-verification-depth). The default value is 10.
159
159
| `auth_oauth2.https.peer_verification` | Configures [peer verification](ssl#peer-verification). Available values: `verify_none`, `verify_peer`. The default value is `verify_peer` if there are trusted CA installed in the OS or `auth_oauth2.https.cacertfile` is set. <p/> **Deprecated**: This variable will be soon replaced by `auth_oauth2.https.verify`. Users should stop using this variable.
160
160
| `auth_oauth2.https.fail_if_no_peer_cert` | Used together with `auth_oauth2.https.peer_verification = verify_peer`. When set to `true`, TLS connection will be rejected if the client fails to provide a certificate. The default value is `false`.
@@ -164,7 +164,7 @@ In chronological order, here is the sequence of events that occur when a client
164
164
| `auth_oauth2.verify_aud` | Whether to verify the [token's `aud`](#token-validation) field or not. The default value is `true`.
| `auth_oauth2.default_oauth_provider` | ID of the OAuth 2.0 provider used for the `auth_oauth2.resource_servers`, that did not specify any (via the variable `oauth_provider_id`) or when `auth_oauth2.jwks_url` and `auth_oauth2.issuer` are both missing.
167
+
| `auth_oauth2.default_oauth_provider` | ID of the OAuth 2.0 provider used for the `auth_oauth2.resource_servers`, that did not specify any (via the variable `oauth_provider_id`) or when `auth_oauth2.jwks_uri` and `auth_oauth2.issuer` are both missing.
168
168
169
169
170
170
#### Resource Server ID {#resource-server-id}
@@ -219,7 +219,7 @@ The following configuration sets the JWKS endpoint from which RabbitMQ downloads
@@ -245,7 +245,7 @@ Each `auth_oauth2.resource_servers.<id/index>.` entry has the following variable
245
245
246
246
All available configurable parameters for each OAuth 2 provider is documented [in a separate section](#multiple-oauth-providers-configuration).
247
247
248
-
Usually, a numeric value is used as `index`, for example `auth_oauth2.resource_servers.1.id = rabbit_prod`. However, it can be any string, for example `auth_oauth2.resource_servers.rabbit_prod.jwks_url = http://some_url`. By default, the `index` is the resource server's id. However, you can override it via the `id` variable like in `auth_oauth2.resource_servers.1.id = rabbit_prod`.
248
+
Usually, a numeric value is used as `index`, for example `auth_oauth2.resource_servers.1.id = rabbit_prod`. However, it can be any string, for example `auth_oauth2.resource_servers.rabbit_prod.jwks_uri = http://some_url`. By default, the `index` is the resource server's id. However, you can override it via the `id` variable like in `auth_oauth2.resource_servers.1.id = rabbit_prod`.
249
249
250
250
Here is an example which configures two resources (`prod` and `dev`) which are used by the users and clients managed by
251
251
the same identity provider whose issuer url is `https://my-idp.com/`:
@@ -268,7 +268,7 @@ Each `auth_oauth2.oauth_providers.{id/index}` entry has the following sub-keys.
268
268
| `discovery_endpoint_path` | The path used for the OpenId discovery endpoint. Default value is `.well-known/openid-configuration`
269
269
| `discovery_endpoint_params` | [List of HTTP query parameters](#discovery-endpoint-params) sent to the OpenId discovery endpoint.
270
270
| `token_endpoint` | The URL of the OAuth 2.0 token endpoint. Optional if you configured `issuer`.
271
-
| `jwks_uri` | The URL of the [JWKS endpoint](#jwks-endpoint). According to the [JWT Specification](https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.2), the endpoint URL must be https. <p/>**Warning**: RabbitMQ uses for each OAuth Provider the variable name `jwks_uri` used by the OpenId Connect Discovery Specification rather than `jwks_url`. This variable is optional if you set `issuer`.
271
+
| `jwks_uri` | The URL of the [JWKS endpoint](#jwks-endpoint). According to the [JWT Specification](https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.2), the endpoint URL must be https. This variable is optional if you set `issuer`.
272
272
| `https.cacertfile` | Path to a file containing PEM-encoded CA certificates used to connect `issuer` and/or `jwks_uri` URLs.
273
273
| `https.depth` | The maximum number of non-self-issued intermediate certificates that may follow the peer certificate in a valid [certification path](ssl#peer-verification-depth). The default value is 10.
274
274
| `https.verify` | Configures [peer verification](ssl#peer-verification). Available values: `verify_none`, `verify_peer`. The default value is `verify_peer` if there are trusted CA installed in the OS or `auth_oauth2.https.cacertfile` is set.
@@ -412,7 +412,7 @@ the `monitoring` tag will be `my_rabbit.tag:monitoring`.
Before RabbitMQ 3.13, users had to either configure the JWKS endpoint (that is `auth_oauth2.jwks_url` variable) or statically [configure the signing keys](#configure-signing-keys). Now, users only need to configure the OpenID Provider's **issuer** URL and from this URL RabbitMQ downloads the OpenID Provider configuration which includes the JWKS endpoint in addition to other endpoints which will be useful in other contexts.
415
+
Before RabbitMQ 3.13, users had to either configure the JWKS endpoint (that is `auth_oauth2.jwks_uri` variable) or statically [configure the signing keys](#configure-signing-keys). Now, users only need to configure the OpenID Provider's **issuer** URL and from this URL RabbitMQ downloads the OpenID Provider configuration which includes the JWKS endpoint in addition to other endpoints which will be useful in other contexts.
416
416
417
417
Usually, this **issuer** URL is the same URL configured in the management plugin (`management.oauth_provider_url`). From now on, you only need to configure a single URL, specified by the `auth_oauth2.issuer` variable. Except in edge cases where the **issuer** URL does not host the login page. In those cases, the user configures the login page in the `management.oauth_provider_url` variable.
If you have both endpoints configured, RabbitMQ uses `jwks_url` because it does not need to discover it via the `issuer` url.
433
433
:::
434
434
435
435
:::info
436
-
**Note about TLS variables for the `jwks_url` or the `issuer` url**: TLS variable such as the `cacertfile` are configured as follows regardless which url you are using:
436
+
**Note about TLS variables for the `jwks_uri` or the `issuer` url**: TLS variable such as the `cacertfile` are configured as follows regardless which url you are using:
437
437
:::
438
438
439
439
```ini
@@ -707,7 +707,7 @@ if RabbitMQ nodes `resource_server_id` is equal to `finance`, the plugin compute
707
707
708
708
As long as you have only one OAuth 2.0 provider, you can skip this advanced usage although you can use it.
709
709
710
-
Under the [basic usage](#configure-issuer) section, you configured the `issuer` url or maybe the `jwks_url` along with the TLS variables if needed. This advanced usage configures everything relative to the OAuth provider into a dedicated configuration.
710
+
Under the [basic usage](#configure-issuer) section, you configured the `issuer` url or maybe the `jwks_uri` along with the TLS variables if needed. This advanced usage configures everything relative to the OAuth provider into a dedicated configuration.
711
711
712
712
Here is an example configuration that uses `issuer` to configure the identity provider's URL:
713
713
@@ -782,7 +782,7 @@ All resource servers share the variables you set so far under `auth_oauth2.` suc
782
782
- `scope_prefix`
783
783
- `additional_scopes_key`
784
784
- `resource_server_type`
785
-
- `oauth_provider_id` - This is the identifier of the OAuth provider. It is configured in RabbitMQ. It provides all the variables to contact the authorization server and discover all its endpoints, such as the `jwks_uri` to download the signing keys to validate the token. If this variable is omitted, RabbitMQ looks up the default Authorization Provider's id in the variable `auth_oauth2.default_oauth_provider`, and if it is also omitted, RabbitMQ uses `auth_oauth2.issuer` or `auth_oauth2.jwks_url` to download the signings keys to validate the token.
785
+
- `oauth_provider_id` - This is the identifier of the OAuth provider. It is configured in RabbitMQ. It provides all the variables to contact the authorization server and discover all its endpoints, such as the `jwks_uri` to download the signing keys to validate the token. If this variable is omitted, RabbitMQ looks up the default Authorization Provider's id in the variable `auth_oauth2.default_oauth_provider`, and if it is also omitted, RabbitMQ uses `auth_oauth2.issuer` or `auth_oauth2.jwks_uri` to download the signings keys to validate the token.
786
786
787
787
The list of supported resource servers is the combination of `auth_oauth2.resource_servers` and `auth_oauth2.resource_server_id`. You can use both or only one of them.
0 commit comments