Add option to require admin verification to enable new account

[cmd-ntrf]

What? This gives the ability to FreeIPA admins to manually activate accounts after they have been created. This option is mutually exclusive with require_verify_email.

Why? I have developed for Compute Canada the project Magic Castle that deploys Slurm clusters in the cloud for training and development purposes. It uses FreeIPA for DNS and user management.

For workshops using a Magic Castle cluster, we currently generates a number of guest accounts with common password and distribute those to participants.

Mokey (which is great, thank you for building it!) enables us to have attendees register themselves, but we would like to be able to validate manually the account request before allowing the user access to the cluster. The account activation will be done through the FreeIPA admin portal.

Why Draft? I am marking this as a draft request as I am open to discussion on the implementation, name and documentation of the proposed feature. This is meant as a functional starting point that currently satisfies the need exposed in the background.

[aebruno]

@cmd-ntrf This all sounds great. Here's some initial thoughts/feedback:

The proposed config param disable_new_user feels like it could be easily confused with enable_user_signup. I propose the following and open to suggestions:

We name the param require_verify_admin to be consistent. So one must first enable self-service user signups with the config param enable_user_signup. Then can optional enable require_verify_email which disables the user account until the email is verified OR require_verify_admin which keeps the user account disabled until a FreeIPA admin manually enables.

We could also create a new param require_verify to be a string with valid options "email or admin". However this would be a breaking change and not sure it buys us much.

Thinking long term, would be great if these two options (require_verify_email and require_verify_admin) did not require mutual exclusivity. I could see a use case where both options could reasonably be required. i.e. we want the user to verify their email AND require a FreeIPA admin to enable the account on the backend. This would require storing some state in mokey which I've been trying to avoid as much as possible. I'm not sure if FreeIPA has any place to store some of this state but may be worth exploring at some point.

[cmd-ntrf]

Thanks for the quick feedback!

I have renamed disable_new_user to require_verify_admin and fix the documentation accordingly.

I agree that ideally both admin and email verification should not be mutually exclusive. 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. Stage user life cycle is described in this document.

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.

The preceding scenario is based on my understanding of the refered FreeIPA user lifecycle document not actual experience with stage user, so I could be overlooking something. It would require implementing the stageuser_add API command in goipa.

[aebruno]

I have renamed disable_new_user to require_verify_admin and fix the documentation accordingly.

Looks good!

I agree that ideally both admin and email verification should not be mutually exclusive. 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. Stage user life cycle is described in this document.

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.

The preceding scenario is based on my understanding of the refered FreeIPA user lifecycle document not actual experience with stage user, so I could be overlooking something. It would require implementing the stageuser_add API command in goipa.

The above sounds great and leveraging the FreeIPA user life cycle management would be ideal. This would take a bit of effort so we can punt on this for now and perhaps look at implementing in the next major release.

I think what you have here looks great. Thanks for contributing!

[cmd-ntrf]

I have renamed the issue to better reflect the feature.

This is good to merge on my side.

[aebruno]

Thank you!