Different behaviour for verify_enrollment setting

Question
1

I want to know if an user has enrolled its token. So the verify_enrollment sounds like the option to
set. I have set this option but this behaves different in 3 tests I did.

My setup is:

  • Privacyidea 3.8.1
  • Keycloak 20.0.3
  • keycloak provider 1.2.0

Via the privacyidea web interface everything is correct and I see the enroll status and it works as expected.

Now via keycloak. The privacyidea plugin can be configured with “service account/enabling trigger challenge” or “enabling sending password”. Both scenarios do not work and behave different.

The first with service account. I see the enroll status to verify but I can not verify it and keycloak display a message that the token must be verified.

The second enabling sending password the token is enrolled but no enroll token status at all, but the user can login with the OTP value provided.

Shoud it not behave the same for all the 3 scenarios?

2

verify_enroll is not supported in the KC plugin. It makes no sense.
If you do validate-check-enrollment and the user is able to login, he successfully enrolled.

If you do validate-check-enroll disable verify_enroll! (or only IP specific)

3

Just back from holidays. I do no why it does not make sense. We have the enrollment via KC and the user forget to scan the QR code or the time has been expired. Plenty of scenarios that the user did not setup its token correctly. How do we detect this situation?

For me it seems logical to the the enrollment status. I forgot the name that also joined the webinar he raised the same question?

4

You could always have the problem, that something happens.
At the end of the day the browser could crash.

OK, here is my quick suggestion:

  1. Use an event handler to set the enroment date of a token as a tokeninfo.
  2. If the user enrolls the token and successfully logs in, this token will have a last_auth_success entry in the tokeninfos.
  3. Now you can seach for all tokens, that have an enrollment date that is older than …whateveryouchoose… but does not have a last_auth_success set. This way you will know, that the token was enrolled e.g. 10 minutes ago but was not used for authentication.
5

Thanks will try this scenario