[keycloak-dev] Suggestion of fields covered by Vault SPI
Michal Hajas
mhajas at redhat.com
Fri Aug 23 06:08:59 EDT 2019
Thank you for responding Stian. Comments below.
On Thu, Aug 22, 2019 at 1:58 PM Stian Thorgersen <sthorger at 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
More information about the keycloak-dev
mailing list