Minimal support for external SSO-based keys

[rgregg]

I know the history of #6949 and the security concerns around key-connector. I'd like to propose a another approach from what was in included in that PR - a minimal set of changes to VW that would allow it to work with a key-connector service implemented elsewhere. The goal being that there is only a small footprint in this codebase, locked down by default, to ensure there is minimal maintenance added to @dani-garcia and other maintainers.

I think the changes to vaultwarden would roughly required (based on a little spike I built):

config.rs

• New setting sso_key_connector_url which would be the URL for the connector service
• New setting for an sso JWT claim to indicate the user is required to use key-connector

schema.rs

• One DB column to track users.uses_key_connector

new api/core/key_connector.rs

• Two new API endpoints - /accounts/set-key-connector-key and /accounts/key-connector/confirmation-details/ to allow the web client to work

identity.rs

• Updates to provide UserDecryptionOptions to clients to support KC or password

And probably a few other changes along the way, but overall it should be a small PR. The rest of the logic for the actual SSO key connector could be build from scratch based on those APIs and the protocol used by the BW clients.

Would a change like this be something that would be considered for the VW project -- given I know the overall feature has been panned by the maintainers, but would be valuable to many folks using VW, I'd love to find a way to make it happen.

Thanks for consideration - rgregg

[acul021]

I only found this discussion after building pretty much what you describe: #7419. It ended up with almost the same footprint as your list, the account endpoints, one uses_key_connector column, the decryption options in the login response, and config options that are only accepted together with SSO_ENABLED. One difference: instead of a JWT claim, enrollment is offered to SSO users without a master password while the option is on.

The connector itself lives outside the codebase entirely (https://github.com/acul021/key-connector), worked out from the client protocol.

[rgregg]

Nice! I'll have to take a look at what you made.