Automatic email token enrollment if user hasn't it

1

Hello, I’m new on privacyidea.
I’d like to automatically enroll email token to users that hasn’t that token already, when they logon to webui, and ask the email OTP in the same session; I am able to do that using a pre auth event handler, but without checking if the user has already an email token assigned.
Is it possible to create such a condition, or do I have to use a custom script action ?
Thanks
Marco

2

You can do that with policies:

  1. in authentication policy, set:
  • otppin - userstore
  • passOnNoToken - enable
  1. in webui policy, set:
  • default_tokentype - email
  • login_mode - privacyidea
  • tokenwizard - enable
  1. in enrollment policy, set:
  • verify_enrollment - EMAIL SMS TOTP HOTP

That should do what you want :slight_smile:

You can also limit maximum number of tokens issued for user/token type etc. The policy system is pretty powerfull.

The way we do it is to set token timestamp on creation with events and then in cron, we delete all tokens not verified with timestamp older than 5 minutes. This way, there are no unverified tokens in the system and we can limit number of tokens per type to 1 for users.

To do this, set event for token_init, Handlermodule token and Position post.
Action: set tokeninfo, key timestamp, value {current_time}

Then in server cron, add:

* * * * * /opt/privacyidea/bin/privacyidea-token-janitor find --tokeninfo-key timestamp --tokeninfo-value-before "$(date +'\%Y-\%m-\%d \%H:\%M:\%S.\%6N\%z' --date 'now - 5 minutes')" --tokenattribute rollout_state --tokenattribute-value verify --action delete >> /var/log/privacyidea-cronjob.log
3

Hello Gryffus, thank you very much for the answer!
I’ve tried and it works well, but there’s a detail that I didn’t write in my post: I want that users can enroll an email token only if they don’t have any token (e.g. first time logon on PI server), but after I want they can enroll TOTP only. That’s because in case they loose their TOTP token, they can logon on PI server using an email token and reset their TOTP token; giving them the possibility to enroll an email token can lead to confusion, I think.
Maybe an approach could be to have a policy for users without email tokens (or without tokens at all) and a policy for user with an email token enrolled and active, I’ll try to see if policy conditions can handle it

Thank you very much for the hints to manage unverified tokens; I’m very impressed with the power of PrivacyIdea! :slight_smile:

Thank you