X.509 certificate based auth on AMQP 1.0

[inseroaj]

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

According to Access Control - Certificate Authentication, X.509 certificate based auth is possible using the built-in rabbitmq-auth-mechanism-ssl plugin.
However, this does not seem to work with AMQP 1.0, probably due to the statement in AMQP 1.0 docs:

For AMQP 1.0 connections, RabbitMQ requires the use of Simple Authentication and Security Layer (SASL) [...]. If the client does not use SASL, RabbitMQ will reject the connection [...].

Describe the solution you'd like

It would be nice for this to work for AMQP 1.0 as well. Is this on the roadmap, and what is the timeframe?

Additionally, it would be nice if permissions could be derived from an external OIDC identity provider, rather than the built-in user system in RabbitMQ.

Describe alternatives you've considered

No response

Additional context

No response

[michaelklishin]

@inseroaj we do not guess in this community. A problem defined as "this does not seem to work" is not something our team will spend any time on, in particular since our Community Support policy very explicitly states that we won't debug TLS-related behaviors for non-paying users.

The x.509 certificate authentication mechanism should work for AMQP 1.0 because it does work for certain Tanzu RabbitMQ-specific features that are based on AMQP 1.0. The mechanism also works for MQTT and STOMP.

It's on you to prove with an executable example (use tls-gen to generate a basic self-signed certificate chain) that the AMQP 1.0 implementation is somehow incompatible with the TLS authN/authZ mechanism, not on us to prove that there are no issues.

[michaelklishin]

The only open source RabbitMQ change that was necessary for an AMQP 1.0-based Tanzu RabbitMQ feature (Schema Definition Sync, a.k.a. the SDS) to work with x.509-based certificate authentication was this change to the Erlang AMQP 1.0 client #11984.

The AMQP 1.0 connection implementation did not need any changes.

The AMQP 1.0 Erlang client change shipped in 4.1.0 and in open source RabbitMQ, primarily affects AMQP 1.0 Shovels. Federation and other features do not use AMQP 1.0.

We also had to contribute x.509 certificate-based support to some newer clients, such as rabbitmq/rabbitmq-stream-dotnet-client#274.

[michaelklishin]

A potentially relevant change in the server that expands how the x.509 certificate-based authN can be configured #2984. It shipped in 3.8.15 several years ago.

[michaelklishin]

And finally, here is a relevant test case in our AMQP 1.0 (server) implementation integration test suites and in the Java AMQP 1.0 client ones.

[michaelklishin]

A documentation update to make it clear that the EXTERNAL mechanism should work for AMQP 1.0 clients will go live in some 6-7 minutes.

[inseroaj]

Thank you for clarifying that.
We just assumed that it wouldn't work, since it said connections would be rejected when not using SASL, and therefore didn't investigate further.
We'll try again to see if we missed something else, and get back if we still encounter issues.

[michaelklishin]

The docs were clarified, thanks for bringing this question up.

[inseroaj]

For future reference:
We used the amqpnetlite library for connecting to RabbitMQ, and it turned out that we didn't explicitly specify the auth mechanism client-side, which caused RabbitMQ to expect SASL PLAIN credentials.
In other words, adding this option (for amqpnetlite) fixed the issue:

Connection.Factory.SASL.Profile = SaslProfile.External;