Re: [mosquitto-dev] Mosquitto authentication plugin suggestions

[Roger Light <roger@xxxxxxxxxx>]

Hi Bart,

Thanks for the feedback. As I mentioned on irc, it's good timing - one
of the things I want to review for 1.5 is authentication and access
control. If anybody else has comments on this (or anything else of
course) then I'd be pleased to see them on the mailing list - the
changes will need a new version of the authentication plugin interface
so it is a good time for breaking changes. There are a few related
bugs in bugzilla already.

I like the idea of multiple plugins and being able to defer calls. It
should be fairly straightforward to implement as well.

Length argument for the password argument - yup, why not.

Cheers,

Roger

On Mon, Apr 13, 2015 at 2:15 PM, Bart <bart.bes@xxxxxxxxx> wrote:
> Dear all,
>
> This weekend I started and mostly finished a Kerberos 5-based authentication
> plugin for mosquitto (https://github.com/bartbes/mosquitto-krb5).  I would
> like
> to briefly discuss my experiences with the plugin interface, followed by
> what I
> think is the biggest shortcoming of the current interface, and a suggestion
> to
> improve that situation.
>
> As those familiar with Kerberos may know, it is a protocol designed solely
> for
> authentication, and does not provide any mechanisms for authorisation. This
> stands in immediate contrast with the plugin API, considering an
> authentication
> plugin is expected to implement not only username/password checking, but
> also
> ACL checking and possibly authentication based on TLS-PSK. As it stands, the
> krb5 plugin is mostly useless (which is no less than I had hoped for in this
> weekend project), as it provides no access over TLS-PSK, but more
> importantly,
> grants everyone read/write access to every topic, as long as they have a
> valid
> kerberos ticket to authenticate with.
>
> As a small aside, one problem I ran into, both on the broker and on the
> client,
> is that (lib)mosquitto deals with passwords as null-terminated strings,
> whereas
> the MQTT 3.1 specification specifies UTF-8 strings with a specified length
> (note
> that UTF-8 strings can contain null bytes), and MQTT 3.1.1 specifies the
> password field as binary data. As it is, I am escaping null bytes in the
> binary
> kerberos data transmitted, which works, but it would have been nicer if this
> had not been necessary.
>
> My largest gripe with the plugin interface as it is right now is that only
> one
> plugin can be active at any given time. The krb5 plugin is intended to play
> a
> largely supplementary role, yet the only option at the moment is to have it
> replace existing authentication. Rather than split up the plugins, I realise
> authentication and authorisation are usually tightly coupled, and I would
> therefore suggest the option of allowing multiple plugins at once.
>
> My suggestion is inspired by PAM, which allows a plugin to either grant
> access
> immediately, deny access immediately or to "defer" action. Now, PAM has a
> much
> more complicated setup, but these three actions should suffice for
> mosquitto, in
> my opinion. The authentication/authorisation workflow would consist of the
> following steps.
>
>  - If the plugin returns MOSQ_AUTH_GRANTED, access is immediately granted,
> the
>    user authenticated correctly, obtained the requested access if this is an
> ACL
>    call, or provided a correct TLS-PSK.
>  - If the plugin returns MOSQ_AUTH_DENIED, access is immediately denied, the
>    plugin has an explicit rule to deny this action, either this user does
> not
>    match some criteria but does exist, the password did not match or access
> to
>    this topic is definitely denied.
>  - If the plugin instead returns MOSQ_AUTH_DEFERRED, the next plugin in the
>    (configuration) list is invoked.
>  - If at the end of authentication/authorisation the status is
>    MOSQ_AUTH_DEFERRED, there was no plugin granting access, so it is then
>    denied.
>
> This, to me, seems like a relatively small modification to the plugin
> architecture that would greatly enhance the possibilities the owner of a
> broker
> has. In my case, I would first allow krb5-based authentication, then fall
> back
> to the inbuilt mosquitto behaviour, allowing private key authentication and
> lastly, passwords. Similarly, since the krb5 plugin has no information about
> ACL, it would immediately return MOSQ_AUTH_DEFERRED, and the normal ACL file
> would get used.
>
> Of course this is only a suggestion, and I would appreciate any feedback you
> may
> have, I would much rather have a good plugin architecture than have my way.
>
> Sincerely,
> Bart
>
> P.S. Sorry about the length, I guess the same burst of inspiration that got
> me
> to write the plugin in the first place also hit me while writing this email.
>
> _______________________________________________
> mosquitto-dev mailing list
> mosquitto-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/mosquitto-dev