[rabbitmq-discuss] Announcing: rabbitmq-proxyauth: A RabbitMQ Proxy Authentication patch/Plugin

[Scott Brooks]

Ok, I'll see what I can do for points 2/3

For #1, I guess I would need to make it so permissions can be set on
non existent users then?
$ rabbitmqctl set_permissions unknown_user '.*' '.*' '.*'
Setting permissions for user "unknown_user" in vhost "/" ...
Error: {no_such_user,<<"unknown_user">>}

Also, here is the use case I'd be looking to use this to solve.
I'm exposing RabbitMQ to the Internet, and don't want to have to share
a username/password.
I also don't want to have to maintain two sets of users, and two sets
of passwords/permissions.

Assuming I do the above so you can set permissions ahead of time for
all your users, it's not really much more work to just create the
users then as well.

Maybe my understanding of the problem domain doesn't quite match
yours, but I don't see how just doing authentication only is
worthwhile.

Scott

On Mon, Jul 26, 2010 at 3:44 AM, Matthias Radestock
<matthias at rabbitmq.com> wrote:
> Scott,
>
> On 22/07/10 05:11, Scott Brooks wrote:
>>
>> TLDR: proof of concept patch to rabbitmq-server, plugin, and ruby
>> backend to authenticate users.
>> http://github.com/Blaze74/rabbit_proxyauth
>> http://github.com/Blaze74/proxyauth.rb
>
> some comments on the server patch:
>
> 1) I'd prefer if this dealt with authentication only, not also
> authorisation. The latter is very rabbit-specific and likely to change in
> the future.
>
> 2) Your rabbit_access_control_proxy module should have an API that performs
> the gen_server calls, i.e. the interface to it should be a set of functions
> (e.g. authenticate(User, Pass) -> boolean()), not a set of gen_server
> messages. That's a general OTP design principle.
>
> 3) The authentication backend should be configurable via an
> "authentication_module" app env var, and the default setting should point to
> a module which refuses all authentication requests (i.e. returns 'false' in
> the authenticate/2 call).
>
> The objective of 2 and 3 is to allow a plug-in to override the default
> setting for the authentication_module with a conforming alternative
> implementation. For an example of how to structure 2 and 3 (including
> behaviour definitions, spec files etc) take a look at the
> backing_queue_module setting in 'default'.
>
>
> Regards,
>
> Matthias.
>