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

[Simon Lundström]

On Tue, 2012-11-13 at 13:11:48 +0000, Simon MacMullen wrote:
> For authentication the backends are tried in order. The first to
> return a #user{} wins. If none returns a #user{} the login is
> rejected.
> 
> For authorisation, we go back to the module in the user's
> auth_backend field.

Aah, makes sense.

> >What we want it only to provide authN with rabbit_auth_backend_kerberos
> >and thus implement check_vhost_access and check_resource_access to only
> >return true(?).
> >Then we want rabbitmq_auth_imaginary to implement check_vhost_access and
> >check_resource_access to do real checks and for check_user_login only
> >return false(?).
> 
> That could work if rabbit_auth_backend_kerberos sets
> user.auth_backend = rabbit_auth_backend_imaginary.

Ah ok, so we have to go that path (see my other reply to your first
mail(!)).

> >Would this work or?
> >
> >Is it possible to use authZ from rabbit_auth_backend_internal? I.e. can
> >I set up permissions and roles for "fake" users (which isn't
> >`rabbitmqctl add_user`:ed)?
> 
> No, the users have to exist.
> 
> >Or I mean, I know I can't (because I get an
> >"Error: no_such_user:" error) but would it be possible to do that some
> >how (like by adding an entry in the correct place in Mnesia)?
> 
> If you are going to create permissions for each user in Mnesia, why
> not create the user as well? You can create a user without a
> password.

This is an acceptable workaround until we have our authZ backend in
place.

> So I guess that's what you want - create users without passwords in
> the internal DB, and have rabbit_auth_backend_kerberos create a
> #user{} at login with auth_backend = rabbit_auth_backend_internal.

Yep!

> >>>heh, and RabbitMQ starts and "accepts" the connection but some how it fails
> >>>anyway.
> >>
> >>You have not provided the error message, and the code looks like it
> >>should work. Try to run individual parts of your solution in
> >>isolation and make sure they work correctly before composing them.
> >
> >That is because I couldn't find one. But Simon pointed out that it was
> >in the SASL log (which I had looked in when I had a previous issue and
> >then nothing was there, but not this time of course... = ).
> >
> >My AMQP client just said "AMQP broker closed TCP connection before
> >authentication succeeded: this usually means authentication failure due
> >to misconfiguration.".
> 
> Yeah, we're not going to give out any information over the network
> in this case - big security concern :-)

= )

Thanks!
- Simon