Central password reset without email

[danbjoseph]

We have POSM, a software to more easily install a number of different mapping and data collection softwares (currently OpenStreetMap, Field Papers, OpenDroneMap/WebODM, OpenMapKit-Server) on portable hardware (designed for an Intel NUC) for use in prolonged activities in offline environments. We're currently working with ToggleCorp on several improvements including an integration of ODK Central.

The WIP is here:

Add odk-central to POSM

We've currently forked central-frontend and central-backend - mostly, as I understand it, in order to make some modifications allowing a Central admin to reset a user password and get access to the link to then copy/paste the link to complete the process. Since Central is running on local hardware, the password reset email can't get out to the Central user.

POSM doesn't support HTTPS; since it's intended for use offline and should be predictable, it has a hard-coded hostname (posm.io, with optional subdomains) and acts as a captive portal to intercept all DNS requests and resolve them to itself. We've talked about registering custom subdomains and using Let's Encrypt, but it gets complicated pretty quickly, especially when the hostnames need to be distinct. POSM is typically deployed to controlled environments for limited time periods, so we prioritize flexibility over strict security.

Setting passwords through the command line is not sufficient because POSM once setup is intended to be easily used by program managers not necessarily comfortable with that. We need a way for a Central admin to set and reset user passwords.

The current solution is to allow an initial password to be set on creation of a user:

And modifying the rest functionality to provide the URL instead of email it.

@ln mentioned in Slack that "One thing we’d likely like to have is the ability for admins to reset user passwords." It would be great if we could somehow contribute the functionality we need to core Central, so we don't have to fork. This is related to another desire to have stand-alone Central installations on portable hardware (possible on a Raspberry Pi?) for offline and disaster environments. Which would require the same password set/reset functionality.

Additionally, guidance on easing the keeping of our Central integration up-to-date would be much appreciated. @issa mentioned "there are more components now than just frontend/backend, and soon to be even more." Is there a better way to do the integration?

[issa]

@ln mentioned in Slack that "One thing we’d likely like to have is the ability for admins to reset user passwords."

wait, don't we have this? or do you mean without sending an email?

Additionally, guidance on easing the keeping of our Central integration up-to-date would be much appreciated. @issa mentioned "there are more components now than just frontend/backend, and soon to be even more." Is there a better way to do the integration?

yeah, this is a difficult area to manage. there are incredibly few of us and there already exists user documentation, installation documentation, and api documentation. i have always been resistant to supporting any installation method besides our fully packaged docker solution because doing extensive custom deployment support on top of all this is simply not sustainable. on the other hand, aiding the ecosystem in meaningful projects like this POSM integration is certainly valuable.

for now, i would suggest keeping tabs on the docker configuration in the central repository. for next release, we will be adding enketo to the mix, which will also require two redis instances.

[LN]

@issa

do you mean without sending an email?

Yes, exactly. An admin can currently invalidate a user's password but not set it for them.

From @danbjoseph's scenario description and by looking at the changes that the POSM team has made, it looks to me like enabling admins to provision accounts with passwords and directly reset passwords through the frontend would meet their needs. It is a change from only email address holders having the ability to set their password so some thought needs to go into which user types can do this.

I think this functionality would be useful not just in offline contexts but also as Enketo form filling becomes an option. Provisioning accounts with passwords that get communicated will sometimes be easier than having folks go through their email and set their own password.

@danbjoseph

guidance on easing the keeping of our Central integration up-to-date would be much appreciated

If you didn't have to fork, could you use the standard install?

[danbjoseph]

I don't think we can shift completely to the standard install as "Docker Compose can't be dropped in directly, but the configs can be adapted for use with systemd and the Nginx reverse proxy."

[LN]

It's not clear to me why you wouldn't be able to use Docker Compose but I imagine it has to do with the specifics of other things you want to run on the POSM box. It seems that at least being able to use the configs as a starting point would help.

Perhaps the POSM team could start with a proposal on how more polished versions of the account provisioning and reset features would work? @issa does that seem reasonable?

I think you already know this, @danbjoseph, but to be explicit, Team Central is heads down working to get localization and Enketo integration released by the end of July.

[LN]

I briefly discussed this with @issa and @Matthew_White. We agree that allowing password reset in the frontend would be helpful for folks who can't rely on email. However, this is against security best practices so we'd want to make sure it's not automatically available to all administrators. The general concept we came up with is to either add a new administrative role or add a modifier to the existing one. If an administrator can set other users' passwords, they would see a password field when going to other users' profiles. User creation wouldn't change so the workflow for provisioning web users with passwords would be to create the user without a password, then go to that user's profile, then set a password.

@issa will work on producing criteria and an issue for this so it's easy to jump in and build.