Community
Participate
Working Groups
This was posted on the mailing list: 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.
What would be very good to have is support for ACLs/passwords from files and authentication plugins. I'd like to see files checked first and then auth plugins.
This is now available for testing on the develop branch. I would appreciate any feedback. Please note that this is not the only change to plugins that is planned for 1.5.
As discussed on IRC, I strongly feel that the order should be swapped: first files, then authentication plugins. The reason is that files checking will typically be "cheaper" than whatever an authentication plugin does. For example, we want to keep administrative accounts out of plugin (-databases) so we don't even want the plugin to be invoked for these (even if the plugin can defer -- if it knows what to defer).