This Bugzilla instance is deprecated, and most Eclipse projects now use GitHub or Eclipse GitLab. Please see the deprecation plan for details.
Bug 464543 - Support multiple authentication plugins
Summary: Support multiple authentication plugins
Status: CLOSED INVALID
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Mosquitto (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows 7
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Roger Light CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 458622
  Show dependency tree
 
Reported: 2015-04-13 15:31 EDT by Roger Light CLA
Modified: 2016-09-09 08:58 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Roger Light CLA 2015-04-13 15:31:11 EDT
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.
Comment 1 Jan-Piet Mens CLA 2015-06-04 10:20:22 EDT
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.
Comment 2 Roger Light CLA 2015-06-29 18:33:57 EDT
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.
Comment 3 Jan-Piet Mens CLA 2015-09-29 06:04:35 EDT
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).