Replies: 1 comment
-
|
That's not going to be possible - the Admin Token is hashed, not encrypted, and that works because the hashed token is used by Vaultwarden itself. The SSO_CLIENT_SECRET is used to communicate with the SSO IdP, so if the secret was stored in an encrypted form in the Vaultwarden configuration it would have to be decrypted before sending it to the IdP. As a result, the decryption key would also have to be available in the configuration somewhere, and that means anyone who has access to the configuration file could likely also get access to the decryption key. This is very similar to situations where users of servers ask for database passwords to be encrypted in the configuration file, and the same thing applies: unless the database will accept the password in the encrypted form, it has to be decrypted, and now there's another secret which has to be supplied. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hey there,
as I was an SSO user before the merge in this main image I was really happy, that this feature was finally merged. Before the merge I remember that there was a discussion about the location of the SSO settings in the Admin Panel. During the test phase I remember that the SSP Client Secret was located in the read only section, but now it is located in the SSO section where it can be edited without the need of a restart.
Though I understand that reasoning I want to ask you to consider to move the SSO Client Secret either in the Read Only section of the Admin Panel or alternativly add some encryption as it is already done with the Admin Token. Right now, if I save my configuration in the Admin Panel, the SSO Client Secret appears in the config.json file as an unencrpyted value.
When the Client Secret was located in the read only section, I included it with a podman secret, which was working fine. I am doing the same for my database url, which is not present in the config.json-file.
Maybe the best way would be to add encryption like you do with the Admin-Token.
Beta Was this translation helpful? Give feedback.
All reactions