support for silo with local users and passwords

[davepacheco]

Motivation

RFDs 57 and 234 talk about the need to support local-only user credentials (i.e., users not from an IdP) for two main reasons:

• to authenticate via the web console for initial setup (which would include IdP setup, so at this point there is no IdP configuration yet)
• to recover a rack if something terrible has happened to the configured IdP or the rack's connection to it

A secondary use case is to deploy in proof-of-concept environments, where a customer doesn't yet want to deal with the red tape of getting their IT team to approve integration with the company IdP. This is obviously a little risky because that POC may turn into production. (Is that our problem? Should we discourage that by restricting capabilities or functionality here?)

Implementation notes

RFD 234 section 1.4 phrases this in terms of a Recovery Silo with local-only users (i.e., no external IdP configuration). These users would have privileges to modify the IdP configuration for other Silos or create new Silos. It's worth noting that this privilege can be escalated to nearly full access to the rack, but it takes some work.

The plan here is to implement password-based authentication for Silos with local-only users. Yubikeys or similar devices have also been discussed. The consensus as I understand it is that this would be nice, but there's a bunch more to work out here that makes it a post-MVP item.

There are obviously significant security considerations here and we should be very careful. OWASP has some detailed guidelines on storing passwords for web applications. I expect we'll want to use a salt and an expensive KDF like Argon2id, scrypt, bcrypt or the like.

Pieces

We need to implement:

• a new Silo type that supports local-only users
• password storage and verification
• reset password flow -- how would this work? do we have the ability to email people? why would we think we'd be able to email people when this was needed? in the common case that this is really only used for a disaster, we can't assume anybody (e.g., another administrator) can log in at all.)

Can we skip implementing groups?

[davepacheco]

See RFD 321.