58 introduced the option to require admin verification for new users. However, currently require_verify_admin and require_verify_email are mutually exclusive. I independently implemented a solution where this limitation does not exist but before providing a PR I think we should discuss if the way I implemented it for our organization it is actually the best way to do so.
For require_verify_email I kept the current approach to lock the user. For require_verify_admin I added a table admin_verify to the DB to which an entry is added after email verification. After admin verification the entry is deleted and the user unlocked.
However also in #58 @cmd-ntrf proposed a different approach which I find quite interesting:
To avoid storing state in Mokey, a potential alternative could be that if require_verify_admin is true, Mokey adds a FreeIPA stage user instead of a full fledge user.
As @aebruno commented
The above sounds great and leveraging the FreeIPA user life cycle management would be ideal.
To which I fully agree.
Despite continuing to use it, I consider using NSAccountLock to store email verification as not optimal considering we want to use FreeIPA user life cycle management. But replacing it again creates the need for an additional DB table which I think we agree on should be avoided.
In this workflow, if require_verify_admin is True, Mokey would create a stage user. The admins would then promote the stage user to make it a full user with UID and GID, but maintain the disabled status of the account. The user would also be sent an email with a link to activate the account, but the link would only starting working once the admin has promoted the user from stage to full-fledged.
This implies an order of email and admin verification which is actually the opposite as the one I force in my current approach.
But should we force an order on email and admin verification?
Forcing it in the order email then admin verification means locking only has a meaning in Mokey for stage users. Otherwise I don't see arguments for one or the other.
The admins would then promote the stage user to make it a full user with UID and GID, but maintain the disabled status of the account.
Should this be done only via FreeIPA or should it be possible to do using Mokey? When done via Mokey the user can be notified when their account was verified.
For our organization we added it to Mokey's web interface. This required me to implement group checking for frontend and backend and a corresponding function in goipa.
58 introduced the option to require admin verification for new users. However, currently
require_verify_adminandrequire_verify_emailare mutually exclusive. I independently implemented a solution where this limitation does not exist but before providing a PR I think we should discuss if the way I implemented it for our organization it is actually the best way to do so.For
require_verify_emailI kept the current approach to lock the user. Forrequire_verify_adminI added a tableadmin_verifyto the DB to which an entry is added after email verification. After admin verification the entry is deleted and the user unlocked.However also in #58 @cmd-ntrf proposed a different approach which I find quite interesting:
As @aebruno commented
To which I fully agree.
Despite continuing to use it, I consider using
NSAccountLockto store email verification as not optimal considering we want to use FreeIPA user life cycle management. But replacing it again creates the need for an additional DB table which I think we agree on should be avoided.This implies an order of email and admin verification which is actually the opposite as the one I force in my current approach. But should we force an order on email and admin verification? Forcing it in the order email then admin verification means locking only has a meaning in Mokey for stage users. Otherwise I don't see arguments for one or the other.
Should this be done only via FreeIPA or should it be possible to do using Mokey? When done via Mokey the user can be notified when their account was verified. For our organization we added it to Mokey's web interface. This required me to implement group checking for frontend and backend and a corresponding function in goipa.