Adds a new auth backend that only accepts loopback connections

[aaron-seo]

Proposed Changes

*Missing test cases, but wanted to get review on approach first. Added manual testing steps.

As discussed in #13205, this PR adds a new auth backend that works exactly like the internal one, but only accepts loopback connections. This PR does so by retrieving the socket in the plain auth mechanism and passes the socket through AuthProps to the auth_backend.

I'm able to test localhost connections, but haven't found a reliable way to test non-localhost connections.

It also accepts all loopback connections, not necessary only the loopback_users. This behavior is subject to change and open to thoughts on it.

This PR is also set as draft, because it is missing a test suite for the new auth backend.

Manual testing performed

Setup

1. gmake run-broker
2. Create users and set up tags and permissions

Listing users ...
user    tags
my_nonloopback_user     [monitoring]
guest   [administrator]
my_loopback_user        [monitoring]
...
Listing permissions for user "my_loopback_user" ...
vhost   configure       write   read
/       .*      .*      .*
...
Listing permissions for user "my_nonloopback_user" ...
vhost   configure       write   read
/       .*      .*      .*

Test localhost conections

java -jar perf-test.jar --uri amqp://my_(non)loopback_user:123@localhost:5672
id: test-093303-736, starting consumer #0
id: test-093303-736, starting consumer #0, channel #0
...

Both connect fine

Test non-localhost connections

(Note: I just manually changed rabbit_net:is_loopback/1 to return false to test for now)

java -jar perf-test.jar --uri amqp://my_(non)loopback_user:123@localhost:5672
Main thread caught exception: com.rabbitmq.client.AuthenticationFailureException: ACCESS_REFUSED - Login was refused using authentication mech
anism PLAIN. For details see the broker logfile.
09:23:37.827 [main] ERROR com.rabbitmq.perf.PerfTest - Main thread caught exception
com.rabbitmq.client.AuthenticationFailureException: ACCESS_REFUSED - Login was refused using authentication mechanism PLAIN. For details see t
he broker logfile.
...

Logs look like this for both attempts

...
2025-04-17 09:29:27.249690-07:00 [info] <0.1011.0> accepting AMQP connection [::1]:59451 -> [::1]:5672
2025-04-17 09:29:27.263415-07:00 [info] <0.1011.0> connection [::1]:59451 -> [::1]:5672 has a client-provided name: perf-test-configuration-0
2025-04-17 09:29:27.263463-07:00 [debug] <0.1011.0> Client address during authN phase: {0,0,0,0,0,0,0,1}
2025-04-17 09:29:27.263520-07:00 [debug] <0.1011.0> User 'my_nonloopback_user' failed authentication by backend rabbit_auth_backend_internal_loopback
2025-04-17 09:29:27.263664-07:00 [error] <0.1011.0> Error on AMQP connection <0.1011.0> ([::1]:59451 -> [::1]:5672, state: starting):
2025-04-17 09:29:27.263664-07:00 [error] <0.1011.0> PLAIN login refused: user 'my_nonloopback_user' attempted to log in, but the socket or address was not from loopback/localhost, which is prohibited by the internal loopback authN backend.
2025-04-17 09:29:27.264157-07:00 [info] <0.1011.0> closing AMQP connection ([::1]:59451 -> [::1]:5672 - perf-test-configuration-0, duration: '19ms')
2025-04-17 09:29:27.265272-07:00 [info] <0.1017.0> accepting AMQP connection 127.0.0.1:59452 -> 127.0.0.1:5672
2025-04-17 09:29:27.268408-07:00 [info] <0.1017.0> connection 127.0.0.1:59452 -> 127.0.0.1:5672 has a client-provided name: perf-test-configuration-0
2025-04-17 09:29:27.268437-07:00 [debug] <0.1017.0> Client address during authN phase: {0,0,0,0,0,65535,32512,1}
2025-04-17 09:29:27.268460-07:00 [debug] <0.1017.0> User 'my_nonloopback_user' failed authentication by backend rabbit_auth_backend_internal_loopback
2025-04-17 09:29:27.268558-07:00 [error] <0.1017.0> Error on AMQP connection <0.1017.0> (127.0.0.1:59452 -> 127.0.0.1:5672, state: starting):
2025-04-17 09:29:27.268558-07:00 [error] <0.1017.0> PLAIN login refused: user 'my_nonloopback_user' attempted to log in, but the socket or address was not from loopback/localhost, which is prohibited by the internal loopback authN backend.
2025-04-17 09:29:27.268761-07:00 [info] <0.1017.0> closing AMQP connection (127.0.0.1:59452 -> 127.0.0.1:5672 - perf-test-configuration-0, duration: '3ms')
...

Types of Changes

What types of changes does your code introduce to this project?
Put an x in the boxes that apply

• Bug fix (non-breaking change which fixes issue #NNNN)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause an observable behavior change in existing systems)
• Documentation improvements (corrections, new content, etc)
• Cosmetic change (whitespace, formatting, etc)
• Build system and/or CI

Checklist

Put an x in the boxes that apply.
You can also fill these out after creating the PR.
If you're unsure about any of them, don't hesitate to ask on the mailing list.
We're here to help!
This is simply a reminder of what we are going to look for before merging your code.

• I have read the CONTRIBUTING.md document
• I have signed the CA (see https://cla.pivotal.io/sign/rabbitmq)
• I have added tests that prove my fix is effective or that my feature works
• All tests pass locally with my changes
• If relevant, I have added necessary documentation to https://github.com/rabbitmq/rabbitmq-website
• If relevant, I have added this change to the first version(s) in release-notes that I expect to introduce it

Further Comments

If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution
you did and what alternatives you considered, etc.

[michaelklishin]

@aaron-seo if the goal of this backend is to only allow loopback connections of automation tools, accepting all local connections without requiring them to be whitelisted make sense to me.

I'm not sure I understand the part about testing remote connections. It should be a matter of connecting from any other host?

[michaelklishin]

4.1.0 has already shipped, so the plugin cannot be included into it by definition.

[aaron-seo]

4.1.0 has already shipped, so the plugin cannot be included into it by definition.

Ah, wrote that before 4.1 shipped, will update to 4.2

I'm not sure I understand the part about testing remote connections. It should be a matter of connecting from any other host?

If I'm running locally with gmake run-broker, and the broker is running on localhost, not sure how to connect from another host without port forwarding, etc. I guess I could just not run it locally (or maybe run in on docker containers!) and it would be much easier to test, which I'll try today.