[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