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
Is your feature request related to a problem? Please describe.
The majority of OAuth Providers uses the standard path .well-known/openid-configuration for their OpenId Discovery endpoint. However, Okta seems to use a slightly different value .well-known/oauth-authorization-server.
Currently RabbitMQ management ui has a configuration variable called management.oauth_metadata_url which is used in cases like Okta, where the OpenId Discovery endpoint url is not compliant with the path specified by the spec.
The configuration variable management.oauth_metadata_url was introduced after RabbitMQ introduced auth_oauth2.issuer. Thanks to auth_oauth2.issuer RabbitMQ is able to automatically discover all the other endpoints such as jwks_url. However, RabbitMQ in this particular case only accepted the use of /.well-known/openid-configuration path which is appended to the auth_oauth2.issuer to build the OpenId Discovery endpoint url.
How this change may affect existing users?
There are two types of users which. may be affected by this change. One type of user is currently setting auth_oauth2.issuer and auth_oauth2.jwks_url and management.oauth_metadata_url because their identity provider does not use the standard path .well-known/openid-configuration for the OpenId discovery endpoint. These users will have to remove two settings, management.oauth_metadata_url and auth_oauth2.jwks_url , and add auth_oauth2.discovery_endpoint_path . They clearly benefit from this change even though they have to make these changes.
There is a second type of user who does not want RabbitMQ discover the endpoints such as jwks_uri. They still want to set them by hand. These users though would have to remove management.oauth_metadata_url and replace with it two settings: auth_oauth2.issuer and auth_oauth2.discovery_endpoint_path. Setting the issuer does not automatically imply RabbitMQ will try to download the OpenId configuration. If the user configured the jwks_uri RabbitMQ does not need to download the configuration. However, the management UI will still try to download the OpenId configuration to discover the authorization and token endpoints.
Describe the solution you'd like
The solution proposed here is to add a new configuration variable discovery_endpoint_path to auth_oauth2 and to auth_oauth2.oauth_providers.$name.discovery_endpoint_path.
This change was already implemented by #12258 . Once #12258 is fully merged, it does not make sense to support management.oauth_metadata_url.
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered:
MarcialRosales
changed the title
Deprecate management.metadata_url and move it to auth_oauth2.openid_configuration_path
Deprecate management.metadata_url and move it to auth_oauth2.discoveryendpoint.pathSep 6, 2024
MarcialRosales
changed the title
Deprecate management.metadata_url and move it to auth_oauth2.discoveryendpoint.path
Deprecate management.metadata_url and move it to auth_oauth2.discovery_endpoint.pathSep 6, 2024
MarcialRosales
changed the title
Deprecate management.metadata_url and move it to auth_oauth2.discovery_endpoint.path
Deprecate management.metadata_url and move it to auth_oauth2.discovery_endpoint_pathSep 27, 2024
Is your feature request related to a problem? Please describe.
The majority of OAuth Providers uses the standard path
.well-known/openid-configuration
for their OpenId Discovery endpoint. However, Okta seems to use a slightly different value.well-known/oauth-authorization-server
.Currently RabbitMQ management ui has a configuration variable called
management.oauth_metadata_url
which is used in cases like Okta, where the OpenId Discovery endpoint url is not compliant with the path specified by the spec.The configuration variable
management.oauth_metadata_url
was introduced after RabbitMQ introducedauth_oauth2.issuer
. Thanks toauth_oauth2.issuer
RabbitMQ is able to automatically discover all the other endpoints such asjwks_url
. However, RabbitMQ in this particular case only accepted the use of/.well-known/openid-configuration
path which is appended to theauth_oauth2.issuer
to build the OpenId Discovery endpoint url.How this change may affect existing users?
There are two types of users which. may be affected by this change. One type of user is currently setting
auth_oauth2.issuer
andauth_oauth2.jwks_url
andmanagement.oauth_metadata_url
because their identity provider does not use the standard path.well-known/openid-configuration
for the OpenId discovery endpoint. These users will have to remove two settings,management.oauth_metadata_url
andauth_oauth2.jwks_url
, and addauth_oauth2.discovery_endpoint_path
. They clearly benefit from this change even though they have to make these changes.There is a second type of user who does not want RabbitMQ discover the endpoints such as
jwks_uri
. They still want to set them by hand. These users though would have to removemanagement.oauth_metadata_url
and replace with it two settings:auth_oauth2.issuer
andauth_oauth2.discovery_endpoint_path
. Setting the issuer does not automatically imply RabbitMQ will try to download the OpenId configuration. If the user configured thejwks_uri
RabbitMQ does not need to download the configuration. However, the management UI will still try to download the OpenId configuration to discover theauthorization
andtoken
endpoints.Describe the solution you'd like
The solution proposed here is to add a new configuration variable
discovery_endpoint_path
toauth_oauth2
and toauth_oauth2.oauth_providers.$name.discovery_endpoint_path
.This change was already implemented by #12258 . Once #12258 is fully merged, it does not make sense to support
management.oauth_metadata_url
.Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: