Privacyidea-simplesaml-module v. 2.0.0 authsource

As we need to move from U2F to WebAuthn (still using Yubikeys) I installed the updated Privacyidea-simplesaml-module on our test IdP. Authsource method seems not to work at all while authproc setup does, but will need some tweaking before going to production. The authsource config in authsources.php looks:
‘pi2f’ => array(
‘privacyideaserverURL’ => ‘’,
‘sslverifyhost’ => ‘false’,
‘sslverifypeer’ => ‘false’,
‘realm’ => ‘’,
‘serviceAccount’ => ‘testanv@superadmins’,
‘servicePass’ => ‘***************’,
‘doTriggerChallenge’ => ‘false’,
‘doSendPassword’ => ‘false’,
‘otpFieldHint’ => ‘OTP’,
‘passFieldHint’ => ‘Password’,
‘attributemap’ => array(
‘username’ => ‘cn’,
‘surname’ => ‘sn’,
‘givenname’ => ‘givenName’,
‘email’ => ‘mail’,

(the service account bit was not particularly well documented, had to guess my way there). When testing the authsource in SSP the message is Error : Unable to reach the authentication server (3)
SSP logs quite a number of errors during this process, most of which means little to me, but this one seems weird:
Jan 10 15:25:46 esn-test-idp2 simplesamlphp[874]: 7 [6950280ee4] Form data: username=btw2912, pass=, otp=1234651386, mode=otp, pushAvailable=0, otpAvailable=1, modeChanged=0, webAuthnSignResponse=, webAuthnSignRequest=, origin=, u2fSignRequest=, u2fSignResponse=, message=, loadCounter=1
Jan 10 15:25:46 esn-test-idp2 simplesamlphp[874]: 7 [6950280ee4] Server config:, sslverifyhost=false, sslverifypeer=false, realm=, serviceAccount=testanv, servicePass=’’’’’’’’’’’’’’’’’’’’’’’’’’’’, doTriggerChallenge=false, doSendPassword=false, otpFieldHint=OTP, passFieldHint=Password
Jan 10 15:25:46 esn-test-idp2 simplesamlphp[874]: 7 [6950280ee4] privacyIDEA: client ip:
Jan 10 15:25:46 esn-test-idp2 simplesamlphp[874]: 3 [6950280ee4] SimpleSAML\Error\Exception: Error 8 - Undefined index: privacyideaServerURL at /var/simplesamlphp/modules/privacyidea/lib/Auth/utils.php:48
Jan 10 15:25:46 esn-test-idp2 simplesamlphp[874]: 3 [6950280ee4] Backtrace:
Jan 10 15:25:46 esn-test-idp2 simplesamlphp[874]: 3 [6950280ee4] 5 /var/simplesamlphp/www/_include.php:44 (SimpleSAML_error_handler)
Jan 10 15:25:46 esn-test-idp2 simplesamlphp[874]: 3 [6950280ee4] 4 /var/simplesamlphp/modules/privacyidea/lib/Auth/utils.php:48 (sspmod_privacyidea_Auth_utils::authenticatePI)
Jan 10 15:25:46 esn-test-idp2 simplesamlphp[874]: 3 [6950280ee4] 3 /var/simplesamlphp/modules/privacyidea/lib/Auth/Source/AuthSourceLoginHandler.php:56 (sspmod_privacyidea_Auth_Source_AuthSourceLoginHandler::authSourceLogin)
Jan 10 15:25:46 esn-test-idp2 simplesamlphp[874]: 3 [6950280ee4] 2 /var/simplesamlphp/modules/privacyidea/www/formbuilder.php:72 (require)
Jan 10 15:25:46 esn-test-idp2 simplesamlphp[874]: 3 [6950280ee4] 1 /var/simplesamlphp/lib/SimpleSAML/Module.php:266 (SimpleSAML\Module::process)
Jan 10 15:25:46 esn-test-idp2 simplesamlphp[874]: 3 [6950280ee4] 0 /var/simplesamlphp/www/module.php:10 (N/A)

Server config: looks wrong to me. However, when using the authproc filter method authentication actually works with TOTP, U2F and WebAuthn even though SSP logs a bunch of errors and lines like the one with the strange PI server URL.

I think the setup here is quite straightforward and “vanilla” so I wonder what I am missing here.

Kind regards

it seems in your config you wrote privacyideaserverURL while the code expects privacyideaServerURL. Did you try it with captial S?
I will check if authsource and authproc require different captialization.

The Devil is in the details… Capial S made a dramatic difference! I’m still confused about just how the new SSP module works but at least it does now.

good to hear that it works for you now. If you have any more problems or suggestions feel to post them here or on github.

I’m still sort of struggling with the new simplesaml-module-privacyidea 2.0
I noticed that updates were made in the Githup repo the other day. However, when replacing the privacyidea folder with the new folder from Github, SSP crashes when the module is called. Something related to PILog goes wrong, I can supply logs if that would be interesting.
The authsource mode, which we are not using, is very confusing to me. It could be useful for testing a token, but when going to SSP-address → Authentication → Test configured authsources → Privacyidea it is (at least to me) unclear what is meant by “Username” and “Password” in this situation. Is “Password” the LDAP usersource password or the token PIN + OTP from an app? Both seems to take me to the next phase. There, things get even more confusing to me, and I cannot get past this even though the authentications seem to be accepted by PI. Stuck in a loop and I never see a result page like “Authentication ok” as I do when doing the same with the LDAP authsource.
The authproc mode fortunately works way better. I have some questions though. Some displayed messages are not found in the dictionary (translating relevant messages to swedish). Guess there are limitations, but when the Authenticate against PI comes and I type the token PIN in the OTP field and push “Log in”, then comes a WebAuthn button. Perhaps it could be next to the “Log in” button in the first place (if the user has a WebAuthn token, a U2F-button if user has U2F etc). If the user has only one token it would be great if hitting Enter would be enough here (like the old module worked).
Sorry for lengthy explanation!

Hi again,
please do not just copy stuff from the main branch into your installation, since the repo uses a submodule (php-client, which is also the source of the PILog interface).

In authsource mode, we do the whole authentication - this requires some more configuration in the privacyidea server to work. It is split into 2 steps so that after entering username+“password”, those inputs can be used to trigger challenge-response token to be used in the next step. Since you are not using this mode, i will skip the lengthy description of all that.

In authproc mode, our provider can be just one of many, so username+password has been taken care of before our provider is called. Now, i don’t quite understand what you mean - You enter your token PIN, press ENTER and then you see the same UI with an WebAuthn button?
Did you configure triggerchallenge with a service account?

For the missing translations: Do you just see the text in english then or is there an error or texts completly missing?

This is what I use:
‘authproc’ => [
05 => [
‘class’ => ‘privacyidea:PrivacyideaAuthProc’,
‘privacyideaServerURL’ => ‘’,
‘realm’ => ‘’,
‘uidKey’ => ‘uid’,
‘sslVerifyHost’ => ‘false’,
‘sslVerifyPeer’ => ‘false’,
‘serviceAccount’ => ‘testanv@superadmins’,
‘servicePass’ => ‘**************************’,
‘doTriggerChallenge’ => ‘false’,
‘otpFieldHint’ => ‘OTP’,
‘passFieldHint’ => ‘Password’,
‘enabledPath’ => ‘’,
‘enabledKey’ => ‘’,
‘tryFirstAuthentication’ => ‘true’,
‘tryFirstAuthPass’ => ‘simpleSAMLphp’,
After logging in with username/password, when trying to access a service that requires MFA, this shows up:
(The text “Alternate login options” does not appear to come from the definitions file and wont be translated). Entering the token PIN in the box and pressing enter gives this:
Clicking the WebAuthn button here makes the Yubikey start flashing and touching it takes me to the service.
If I change ‘doTriggerChallenge’ to ‘True’ the PIN for the token is never asked for. After username/password this shows up:
Here, I don’t need to enter any PIN in the box, just clicking the WebAuthn button makes the Yubikey start blinking and touching it lets me in. If I also have registered an U2F token a button labeled “U2F” is shown next to the WebAuthn button.
I don’t really want the Yubikeys to be accepted without entering the PIN that the user entered when the Yubikey was registered as a token.
As for the translations, only the “Alternate…” text and the button labels can’t be translated in the Authproc scenario. In the Authsource scenario there are more phrases that can’t be translated, I think the english text is shown all the time.

Thanks for clarifying. We will add the “Alternate login options” text to the translations. The prompt “Please confirm with your WebAuthn token…” is from the server and has to be translated there.

What you are experiencing is the expected behavior. If you enable triggerChallenge, the account you specified in the config (‘serviceAccount’ => ‘testanv@superadmins’,‘servicePass’ => ‘**************************’) is used to trigger all challenge-response token for the current user. This does not require the token’s PIN and has the advantage that the challenge-response token are ready to use in the second step. In contrast, if you trigger with the PIN, you need 3 steps to login with a challenge-response token (1. username+pw, 2. PIN to trigger, 3. actual token).
If you do not use doTriggerChallenge, you can remove the account credentials from the config, they are used only for that feature.

If you want to use HOTP/TOTP with PIN, you have to enter the PIN followed by the OTP value both into the OTP field.

In your previous response you wrote:

I still don’t really understand that - in which case do you have to “do more” now compared to the old version? Would you like to have your YubiKey flashing instantly without clicking the button?

Thanks for clarifying things for me. What I mean by the old module version is that there was one box where the user entered either only the PIN for the Yubikey or the PIN for the TOTP directly followed by the digits from the app. In the former case the Yubikey started blinking directly after hitting enter and that was that.
With v. 2.0 of the module, TOTP works the same way but when using a Yubikey there appears a new button after entering the PIN. This makes sense if the user have several tokens with the same PIN, but in case the user only has one token registered with the PIN that was entered it would be nice, I think, if hitting “Log in” in the first place triggered that token (Yubikey in our case) directly. This would be effectively the same as how the old module works.
The module is obviously aware of which token that is called for by the PIN as only the relevant button shows. If I register e.g. the same Yubikey as both U2F and WebAuthn with thew same PIN both buttons appear but if I register it with different PINs only the relevant button appears after entering either PIN.
I certainly don’t have the insights to understand how the underlying mechanisms work and what is possible, but I do like the way the old module worked with one input box and one button making it difficult for users to misunderstand how to use it.

I see what you mean. The problem is that we can not assume a user has only the token that were triggered, since some token are not challenge-response. Therefore, we will always have to offer the input field. However, in our keycloak plugin, there is an option to set the preferred token type. If a token of that type is triggered, it will be used directly for authentication without the button press - i will have that implemented for the next version of the ssp module.
The problem with the old module and the Yubikey (or u2f in general) behavior was that if you did not do the stuff with your Yubikey on the first try, you would have to reload the site since there was no option to trigger u2f/webauthn again, so now we have buttons for that.