Bug 51262 - Allow for users to be enabled after verifying their mail address via self service
Allow for users to be enabled after verifying their mail address via self ser...
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: Self Service
UCS 4.4
Other Linux
: P5 normal (vote)
: UCS 4.4-5-errata
Assigned To: Dirk Wiesenthal
Jürn Brodersen
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-05-10 10:31 CEST by Valentin Heidelberger
Modified: 2020-07-29 16:50 CEST (History)
5 users (show)

See Also:
What kind of report is it?: Feature Request
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments
Patch to enable users after completing password forgotten process (1.18 KB, patch)
2020-05-10 10:31 CEST, Valentin Heidelberger
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Valentin Heidelberger univentionstaff 2020-05-10 10:31:33 CEST
Created attachment 10353 [details]
Patch to enable users after completing password  forgotten process

A customer would like all their users to verify their mail address and only be enabled afterwards. Before they shall all be disabled.

They wrote an UDM hook to enable users if UniventionPasswordRecoveryEmailVerified is being set to true. That covers the "verify mail address" workflow. Because they consider someone using their recovery e mail address to reset their password as "verifying one's mail address as well, they also want to enable users completing a password reset. The attached patch does that.

It might make sense to have implement such a workflow as an option in the self service.
Comment 1 Ingo Steuwer univentionstaff 2020-05-12 12:18:36 CEST
The idea behind the existing workflow (enable users directly after registration) is to be able to give users a feedback after authentication - not without authentication. That makes it possible to give end users usefull information without risc of information loss to unauthenticated attackers.

To be included in the product an implementation of an "deactivated" workflow this needs to

- be part of the Self Service
- be configurable (with default "no")
Comment 3 Dirk Wiesenthal univentionstaff 2020-07-21 13:32:28 CEST
In univention-self-service 4.0.3-36A~4.4.0.202007211218, the following is implemented:

For self service plugins that are modeled around passwordRecoveryEmail and the password reset (i.e. for one plugin: "send_email"), passwordRecoveryEmailVerified will be set to TRUE after a successful password reset.

Rationale: If the user reset the password via the token sent to the recovery email, the address is under the user's control. Therefore, we can call it verified if the token was entered correctly.

This solves the problem, because:
The customer already has a UDM hook in place that "enables" users as soon as their passwordRecoveryEmailVerified is set to TRUE.

Doing it indirectly seemed to be the better solution here. Enabling users "out of nowhere" did not feel appropriate for the self service. The mechanism described above feels "natural" and does not need any UCR variable.
Comment 4 Jürn Brodersen univentionstaff 2020-07-22 16:58:38 CEST
What I tested:
Reset my password through the "password forgotten" page -> RecoveryEmail is now verified -> OK

YAML -> OK (a0a20f8bfb)

-> Verified