CustomUserBackend is loaded too late

[stevie-sy]

History

In the meantime, some time has passed as @nilmerg explained me how to create a own custom backend. The requirement was to call Icinga from an application portal (beside the possability via DbBackend) and use its authentication information for the login. Because it's a kind of external backend I should use as role model https://github.com/Icinga/icingaweb2/blob/c4b6e4bdda691820fd3c16841436b2ef796f44b1/library/Icinga/Authentication/User/ExternalBackend.php#L13. Now I have finally managed to do this, but I noticed a few things that I would like to describe here

Describe the bug

During the development I recognized that my module with the own backend is loaded too late and/or the authentifcation call was after putting the credentials into the LoginForm. Depending on the situation icingaweb produces a lot of error messages like: Can't create authentication backend "portal". An exception was thrown: <- Icinga\Exception\ConfigurationError in /usr/share/php/Icinga/Authentication/User/UserBackend.php with message: Authentication configuration for user backend "xxx" defines an invalid backend type. Backend type "xxx" is not supported It doesn't matter in which order I configured my backend and the DbBackend at /etc/icingaweb2/authentication.ini. Because of that I had to debug the complete login sequence.

To Reproduce

The first problem (or actually hurdle) I encourtered is the function https://github.com/Icinga/icingaweb2/blob/c4b6e4bdda691820fd3c16841436b2ef796f44b1/library/Icinga/Authentication/Auth.php#L239 which is triggerd by https://github.com/Icinga/icingaweb2/blob/c4b6e4bdda691820fd3c16841436b2ef796f44b1/library/Icinga/Authentication/Auth.php#L88. The problem what I saw is here, that the function authExternal checks if the backend is a instace of the class ExternalBackend. So If I create my own backend with the implemation of the Interface UserBackendInterface. The function returns false everytime and consequently the authentication fails. Here is the workarround for now that the own backend extends the class ExternalBackend although the most things isn't needed from that class. Maybe to create an own interface, which also will be checked in authExternal instead of the class name? Just to produce nicer code.

The second problem I encourtered is this call https://github.com/Icinga/icingaweb2/blob/c4b6e4bdda691820fd3c16841436b2ef796f44b1/library/Icinga/Authentication/User/UserBackend.php#L91. All installed and activated modules are loaded alphabetically. For example I choose as name for my module "Mybackend". If there are many other modules loaded before like "audit", "icingadb" etc. it takes time, until the own module is loaded. And here happens a big problem: During loading every module and register possible custom backends, following function gets triggerd https://github.com/Icinga/icingaweb2/blob/c4b6e4bdda691820fd3c16841436b2ef796f44b1/library/Icinga/Application/Modules/Module.php#L1374 This function includes the configuration.php and excutes the existing PHP code. If there is a code like (from icingadb-web):

$auth = Auth::getInstance();
$authenticated = Icinga::app()->isWeb() && $auth->isAuthenticated();

the call will fail, because the own modul isn't loaded and the own backend isn't registred yet. This produces the mentioned error message above and happens as long as, until the own module gets loaded! Depending on the number of modules installed, the log file becomes filled with error messages! The only workarround for this is to rename the own module to a little senseless name like "aaamybackend" to provoke the fact that the own module with the own backend is loaded first.

Expected behavior

I know this is a still rare case. Maybe not everybody is crazy like my/us 😆 to create a own backend. So get a solution for this will be low prio I think. For loading in a specific order instead of alphabetical could be to set something like a load order. So that, the call Icinga::app()->getModuleManager()->getLoadedModules() returns the correct and needed order. And for the "problem" with authExternal a solution could be an own interface as I wrote before. But that's only that the code will be nicer, not more. I just wanted to draw attention to it.

Your Environment

Include as many relevant details about the environment you experienced the problem in

• Icinga Web 2 version and modules (System - About): 2.12.1
• Web browser used: Edge (128.0.2739.79) / Firefox (115.15.0esr)
• Icinga 2 version used (icinga2 --version): 2.14.2-1
• PHP version used (php --version): 8.0.30
• Server operating system and version: RHEL 9.4

[nilmerg]

Hi Stevie ;)

Here is the workarround for now that the own backend extends the class ExternalBackend although the most things isn't needed from that class.

Yep. Would be my suggestion as well, though.

because the own modul isn't loaded and the own backend isn't registred yet.

Have you tried putting the registration of your own backend in run.php? It's run early on, earlier than configuration.php, and the supposed location for hooks (which a custom user backend is somewhat) in general.

[stevie-sy]

Yes I tried run.php as well. Didn't work. But I changed my code so many times until it worked at this time. 😄 So it could be an other reason at this time. I will test this for you and report back 😉

[Wintermute2k6]

ref/NC/830526

[stevie-sy]

So testet it. And the result is the same like written above: It doesn't matter if the call $this->provideUserBackend is put into run.php nor configuration.php. The own module which register the own backend must be loaded before every other module which will do some checks within Auth::getInstance(); e.g. icingadb-web is doing.

Until there is no load order, you can only choose a name for the module that will ensure that it ranks first in an alphabetical list like the result of this call Icinga::app()->getModuleManager()->getLoadedModules() in https://github.com/Icinga/icingaweb2/blob/c4b6e4bdda691820fd3c16841436b2ef796f44b1/library/Icinga/Authentication/User/UserBackend.php#L91