Do not require the triggerChallenge

[cornelinux]

I suggest to not always call the triggerChallenge in the BeginAuthentication.

privacyIDEA-ADFSProvider/privacyIDEAADFSProvider/Adapter.cs

Line 52 in 4aebedc

token = otp_prov.getAuthToken(admin_user, admin_pw);

Usual tokens ("Pushbutton tokens") like the Google Authenticator, hardware devices or the YubiKey do not need a challenge to be triggered. Triggering the challenge requires an administrative account to be configured.

The normal pushButton tokens can simply be validated in the TryEndAuthentication.
Thus I suggest to add a check here

privacyIDEA-ADFSProvider/privacyIDEAADFSProvider/Adapter.cs

Line 52 in 4aebedc

token = otp_prov.getAuthToken(admin_user, admin_pw);

:

If no admin account or adminpw is given in the config.xml, the triggerchallenge should not be called.
This also makes setting up the provider much easier.

[sbidy]

Maybe I update also the configuration options for this to get more transparency for the behavior.
Thank you for the suggestion 👍 !!

Only SMS or mail challenge needs to be triggered, I guess?

[cornelinux]

You are right. SMS token and EMAIL Token require a trigger to be sent.
Anyway, you could use triggerchallenge with other Token types like HOTP. Then the user would not have to use a PIN/password, if the OTP is sent after the administrator's triggerchallenge.

Well the normal way to not use a PIN is to use a otppin policy.

[sbidy]

I updated the code and documentation to disable the trigger if no admin user is defined.
But if I send a empty (pass="") authentication request to the pID3A /validate/check nevertheless a challenge is triggered.
I get the following response:
{"jsonrpc": "2.0", "signature": "7159[...]9304", "detail": {"multi_challenge": [{"attributes": {"state": null}, "serial": "PIEM0000C6E1", "transaction_id": "00115556848776113240"}], "threadid": 140714630420224, "attributes": {"state": null}, "message": "Enter the OTP from the Email:", "serial": "PIEM0000C6E1", "transaction_id": "00115556848776113240"}, "versionnumber": "2.21", "version": "privacyIDEA 2.21", "result": {"status": true, "value": false}, "time": 1514906040.647225, "id": 1}

Can I change that behavior at the pID3A? Because in this way it is possible to trigger a challenge for any other user without a admin token.

Should I open a issue at the pID3A for that?
Thanks.

[cornelinux]

With challenge response token privacyidea will trigger a challenge if the user provides the correct OTP PIN or password in the first authentication step. If your OTP PIN is empty, of course an empty PIN will trigger the challenge, since this is the correct PIN.

Of course this will only work with challenge response tokens like SMS and email.

So the question is, which scenarios you want to cover. Since you have not implemented the above mentioned way to trigger a challenge but only the triggerchallenge-API I only see thes3 scenqrios:

1. Use challenge response tokens like SMS and email, but you need to configure the challenge admin. You can also use HOTP or TOTP. This should work fine.

2. You are NOT configuring the challenge admin. I.e. you can not use SMS or email. You can only use HOTP and TOTP and this should also work fine.

[sbidy]

Ah, OK. I didn't configure a PIN for that test token. That's the problem - no PIN = empty PIN then a challenge is triggered. I was confused between the term PIN in case of a token-pin and a OT-Password 😉. Sorry about that.

Yes, that's correct. I only implement the case if a users doesn't provide a admin account in the configuration, than no administrative challenge is triggered.
The other case - a user has a challenge response token with a configured token pin - is not implemented yet. Because I have to alter the authentication page to handle the token pin.

The ADFS auth. page should provide the following steps:

1. Authentication via User+Password provided by the ADFS itself.
2. User must enter the token PIN to trigger a challenge
   (3. If PIN is correct - User receives the challenge with a OTP)
3. The user must provide the OTP from the challenge message to get access

One question: I don't saw a tokenpin property at the API call. The pass property is also the OTP as well as the token password? The privacyidea can distinguish the pin from a OTP value?

Thank you for the correction and help.

[cornelinux]

The other case - a user has a challenge response token with a configured token pin - is not implemented yet. Because I have to alter the authentication page to handle the token pin.

Imho this is not necessary. Since privacyIDEA adds the second factor, you can as well ignore the pin that is managed by privacyIDEA. I.e. in this case you use the challenge admin password.

From a users perspective, I would not want to enter the PIN to trigger the sending of SMS.
The SMS should be sent after the AD pw was entered successfully.

The pass in the API call can either contain:

1. OTP PIN -> trigger SMS/Email
2. OTP PIN + OTP value

[sbidy]

OK, now I should catch the case if no admin account is provided but a challenge-OTP (Mail, SMS...) with a empty PIN in configured for the users.

=> If no admin account is set = no challenge is triggered at any time
=> If an admin account is set = the challenge will be triggered via admin account

=> If a OTP-Token with a PIN is configured = the PIN+OTP will be send to the privacyIDEA. The provider doesn't alter the request in any kind.

Or I'm wrong 😉 ?

[cornelinux]

OK, now I should catch the case if no admin account is provided but a challenge-OTP (Mail, SMS...) with a empty PIN in configured for the users.

How do you want to catch the case. If no challenge admin is defined the user needs to trigger the challenge via providing the PIN. You can not know, if a PIN is empty. So in my opinion you do not need to check this.

Usually the implementation works this way:

1. If an admin account is set, you can do it just like now.

2. If no admin account is set you ask the user for a "password". This password is sent to privacyIDEA in the parameter pass. You do not need to care about what it is, what the user types in! Simply send it to privacyIDEA and take a look at privacyIDEA's response:

2.1. value = true. The authentication was successful. You can grant access.
2.2. value = false: The authentication failed, it was not successful.
2.3. if value was false but the details contain a "transaction_id", you know, that this is the first step of a challenge response authentication. Now you need to show the user a second login screen and again send the user, the pass and the transactionid to privacyidea.

If you want to, we can take a look at it togeather. Are you at FOSDEM by any chance?