Re: [keycloak-dev] Suggestion of fields covered by Vault SPI
Thank you for responding Stian. Comments below.
On Thu, Aug 22, 2019 at 1:58 PM Stian Thorgersen <sthorger(a)redhat.com>
wrote:
- Client secret (should be easy)
>
-1 We should recommend jwt auth or mtls here instead as it provides better
security. When those are used Keycloak only stores the public part so
doesn't need to be stored securely.
Well, you are right. Why do we have secrets then? Can it be removed and
replaced by
jwt or mtls?
> There are also other fields which we were considering, however, we decided
> not to add them for now. Feel free to comment on any of these fields or
> suggest new once. We are open to add any new fields in case of reasonable
> arguments.
>
> - KeyProviders - This part should be probably added soon as some
> follow-up
> work. It might be a little bit tricky as we don't want to duplicate each
> KeyProvider with its Vaul*KeyProvider version.
>
Can't we just add an option to existing providers to be able to load keys
from the vault?
I am sure there is a possibility of how to do it in an elegant way. I
haven't investigated it yet (maybe some else have). The question at the
moment is, whether to include it in the initial implementation or do it as
follow-up work.
- Credential Attributes
>
What credential attributes? Can you give some examples here?
I was not sure what exactly is stored in there, so I rather put it here to
obtain feedback if somebody knows about something which is worth storing in
the vault.
- Federated User Credentials
>
These are just stored as hashed passwords right? As user credentials they
should be encrypted in db not stored in the vault.
It should be the same as User Credentials