Hello all
I use privacyIDEA 3.6
I configured 2 step enrollment token via privacyIDEA authentication app.
Now I want to create Event handler (or other rule/policy) which will delete tokens with the “rollout_state”:“clientwait” for more than 10 minutes old. Please tell me how to configure it? (what other solutions can be?)
P.S. Users can start enrollment token process and not activate the token until the end, but a token will already be assigned to the user. This will result in many tokens assigned to user.
I already limited the number of “max_active_token_per_user”: “1”, “max_token_per_user”: “1”
I want to implement something similar to this:
opened 01:02PM - 16 Sep 16 UTC
closed 07:51PM - 08 Nov 16 UTC
Status: Waiting for feedback
[Feature request]
Now privacyIDEA displays the QR code to the user but privacyID… EA can only assume the user has scanned the QR code.
To verify if the user has in fact scanned the code, this can be done e.g. like Google and Microsoft do: in the page there the qr code is displayed, the user must click "next" and enter the OTP displayed (this way we know for sure the user has scanned and registered the token on his/her device and the token works).
Below is the way Microsoft does (step 4):
![image](https://cloud.githubusercontent.com/assets/1154133/18586753/83c11384-7c1e-11e6-917e-af6485081de3.png)
]
I would suggest privacyIDEA to not create a token for a user unless the user has verified the OTP...
Authenticate user and retrieve authorization token.
Display token QR code and ask for OTP as verification.
Validate Phone part.
If validation succeeded, enable the token.
Otherwise, delete the token.
You need an additional timestamp.
and you can not use an event handler in your case to delete a token!
Use a token event handler to set an arbitrary timestamp during enrollment
use the token-janitor to search tokens with the client_wait state and the corresponding timestampt to delete these tokens.
Thanks for the reply!
I will give feedback when I tune according to your recommendations.
Hello
I configured event handler (set timestamp {current_time}).
However in token-janitor missing function to find rollout_state.
Tell me please how to set it up?
This is currently worked on:
opened 09:26AM - 17 Jun 21 UTC
closed 02:04PM - 12 Jul 21 UTC
Topic: Documentation
Topic: Enrollment
We need to identify tokens that can be in a not finally enrolled state.
This … can be
* push tokens (maybe we need to improve the docs of the TTL, or we can totally remove the TTL and set the default to 2minutes)
* 2step enrollment
* webauthn
* ...
We need to define, what we do with such pending tokens. (see pending certifiate requests?)
What will be do with a push token, that is not scanned and enrolled by the smartphone app in a certain time?
Can we simply do a documentation, where we describe how such tokens can be handeled with the tokenjanitor?
Should we involve the periodic tasks?
We also need to check, that when the token is enrolled finally, that th enrollment state is set correctly and does *not* remain in `client_wait`. (see #2763 )
Note: The TTL in the push token was originially ment to define, for how long the smartphone app should *try* to reach the privacyIDEA server during enrollment, to avoid endless loops. If on the server side the half enrolled push token is not removed, the QR code could be scanned again and enrolled later with another smartphone (if the first enrollment is not finished).
This can be also used as an interesting feature.
# Analysis
The token attribute (DB) `rollout_state` is used in the
* `pushtoken.py` for enrollment and waiting for the 2nd part of the smartphone.
* base class `tokenclass.py` (for 2step enrollment of HOTP and TOTP)
(The TiQR token is actually enrolled in one step)
Possible settings of the rollout_state are currently:
* "clientwait" for 2step enrollment of HOTP and TOTP waiting for the user input and PUSH token waiting for the smartphone response
* "enrolled" only used in Push token, to mark that the token has been enrolled.
Where is the rollout_state already used?
* Event Handlers can already have a condition on the rollout_state.
* Policies can use the token attributes condition, since the rollout_state is a direct token database column.
# Todo
What should we enhance?
* [x] the tokenjanitor should be able to find tokens on the rollout state. Probably we should be able to combine rollout_state and other conditions in the token janitor.
* ~~[ ] ensure that no enrolled token remains in the state `client_wait`.~~
* [x] check with u2f and webauthn: These tokens use internally `self.init_step = [1|2]`. This is simply depending on the the token/init parameter passed. We should add a `rollout_state == clientwait` to the token in the database to indicate also in the database, that the token is not finally enrolled.
# Thoughts about enrollment states
Possible states can be defined as constants in an enrollment-state-classe:
``clientwait``: The token is in a state where the **user** or the **smartphone** has to take action. The server is waiting for the client. This is done in 2step enrollment and push tokens.
``enrolled``: This indicates that the token is enrolled. Currently this state is only set in push-tokens. This state could even be omitted.
``pending``: This would be a state the **user** is waiting for the **server/backend** to finalize the token enrollment. This could be e.g. a certificate request. The certificate would be in the state "pending"; it would be a CSR until it is signed/enrolled by the CA. There might also be other scenarios, where the **user** is waiting for the **server**.
It will be available in v3.7
Great news,
Thanks for the reply!