[rabbitmq-discuss] Creating an auth plugin (Kerberos)

[Simon MacMullen]

On 27/11/12 14:37, Simon Lundström wrote:
> On Tue, 2012-11-27 at 14:01:22 +0000, Simon MacMullen wrote:
>> On 27/11/12 13:48, Simon Lundström wrote:
>>> Would it be OK to just accept all authentications with an undefined
>>> password?
>>
>> Well, you will be asserting that those users exist. So this will
>> happen in two cases:
>>
>> * With 2.x only from mgmt / stomp, where the plugin has already
>> checked the password itself (so you should be fine).
>>
>> * With 3.x and 2.x, with federation / shovel for local users
>> (local_username in federation, "amqp://" URIs in shovel).
>>
>> The second case bears a little thought - although in those cases the
>> username to use is configured by the sysadmin ultimately.
>
> Ugh. It's never easy, huh? = )
>
> But, with federation / shovel are the users authentication in some
> other way first or is the "does this user exist-check" the only
> authentication?

It's the only check. Note that this is not the case for *all* 
connections used by federation / shovel, the remote connections are 
normal AMQP. This is only for connecting into the same broker the plugin 
is running on.

> Is there any way that I can from my plugin see that this is an auth
> request from federation / shovel? This way I could just reject all those
> connections.

When running 3.x you could just reject all passwordless auth requests. 
Any federation / shovel local connections would have to be to a user 
supplied by another auth backend, e.g. the internal one. Since there's 
usually only one such user anyway that shouldn't be too big a deal.

But with 2.x you would reject all mgmt/stomp connections as well. 
Another reason to upgrade...

Cheers, Simon

-- 
Simon MacMullen
RabbitMQ, VMware