Closed libregeek closed 9 months ago
I checked the code in the module, and am fairly certain there is nothing the module code can do wrong to trigger this bug.
Could it be that %precondition itself is buggy, and only works correctly on the first authproc?
Can you invert the positions of webauthn and the-other-module and then see whether the other module still respects %precondition?
What is the first authproc-filter you're running? I'm starting to think that maybe the first one is somehow manipulating the state in an unruly way.
Can you invert the positions of webauthn and the-other-module and then see whether the other module still respects %precondition?
I tried this and the other module respects the %precondition as expected.
I will share the source code of the other authproc filters.
What is the first authproc-filter you're running? I'm starting to think that maybe the first one is somehow manipulating the state in an unruly way.
Here is the source code of the two modules that I tested: https://github.com/libregeek/ssp-sample-authproc
These are not the real modules that we use on the production environment, but we use them in the development/test environment to test the workflows. Both the modules are similar in terms of code and functionality. The only difference is their names.
Once enabled and configured, the module will show a page with a submit button soon after authentication and clicking on the submit button will take the user to the next process filter in the process chain. I used the Webauthn as the third filter in the chain.
@tvdijen Could you please take a look at the source code of the sample module created: https://github.com/libregeek/ssp-sample-authproc. The Controller and Class source code is less than 30 LOC.
@tvdijen @restena-sw Assuming that the problem is with my custom plugins, I created a new plugin (Gamma) by copying the Webauthn plugin source (from Github master branch) and simply renaming all files, classes and templates. Then I installed and configured both the plugins on SSPHP-v2.1.0. I tested the new plugin independently and ensured that is working as the original Webauthn plugin. So here is the test configuration and results:
I used the following configuration in config/config.php
7=> array(
'class' => 'webauthn:WebAuthn',
// '%precondition' => 'return false;',
'default_enable' => true,
'use_database' => true,
'attrib_toggle' => 'toggle'
),
8=> array(
'class' => 'gamma:Gamma',
'%precondition' => 'return false;',
'default_enable' => true,
'use_database' => true,
'attrib_toggle' => 'toggle'
),
The above configuration will not work and Gamma plugin is invoked irrespective of the %precondition
parameter in the config. However, the %precondition
works fine for the below configuration.
7=> array(
'class' => 'webauthn:WebAuthn',
'%precondition' => 'return false;',
'default_enable' => true,
'use_database' => true,
'attrib_toggle' => 'toggle'
),
8=> array(
'class' => 'gamma:Gamma',
// '%precondition' => 'return false;',
'default_enable' => true,
'use_database' => true,
'attrib_toggle' => 'toggle'
),
I think this could be a problem in the SSPHP core. I tried to troubleshoot the issue, but couldn't get any pointers. Any help would be appreciated.
The problem was identified in SSP core and fixed there.
Webauthn does not respect the precondition configuration in SimpleSAMLphp-2.1 when configured for two-factor authentication. This happens only when Webauthn is configured as the second or third process filter in the configuration. It will works fine if it is configured as the first process filter. config/config.php
Please let me know if you need more information to troubleshoot the issue.