Stop storing private keys of SAML clients in Keycloak DB

[Marek Posolda]

Currently for SAML clients, we keep the private keys of the clients
saved in Keycloak DB. I think this is not correct and it will be better
if Keycloak server has access only to the public key of the client and
the private key is saved only on the client's side.

What we can do is, that when administrator is on "Keys" tab of SAML
client and clicks "Generate keys", the Keycloak will generate the
keypair of private/public keypair. But it will save only public key to
the Keycloak DB and the private key will need to be immediatelly
downloaded by the administrator to be saved on the client's side. This
is in fact same, which we already do for OIDC clients.

This option has one small usability concern, that currently when
administrator clicks to the "Installation" tab of SAML client, he has
option to download full configuration of adapter (including private key)
and save it to the adapter's side.

In summmary options are:

1) Don't have private key saved in Keycloak. This means that in the
"Installation" page, there will be some placeholder text, which will
notify administrator, that he needs to manually add the PEM with his
private key. Something like:

                <PrivateKeyPem>
                    REPLACE WITH YOUR PRIVATE KEY
                </PrivateKeyPem>


2) Keep the private key saved on the Keycloak side in the same way like
we are already doing. This will allow to keep showing the private key in
the "Installations" tab.


The option 1 has slightly worse usability. As it means that when
administrator is on the "Keys" tab and he clicks "Generate keys", he
will need to temporary save the private key PEM somewhere. Then in
another step, he will go to the "Installations" tab where he downloads
the adapter configuration with the placeholder text for the private key,
and he will need to replace this placeholder text with the private key
PEM downloaded in the first step.

However my vote is to still go with option (1) . This is the same
behaviour, which we have for the OIDC clients. So it will allow us to
have OIDC and SAML clients consistent. The option (2) is the aligned
with the behaviour, which we have now and it requires client's private
key to be saved in Keycloak DB, which IMO should not be done.

WDYT?

Marek

[Till Markus (IOC/PAU1)]

Hello,
It would also be an idea to have a secure sink like a key vault/HSM where Keycloak has write (but may not modify) access. This is especially useful if the integrated system and Keycloak are maintained in the same organization, also the keys might already get created in that external service (HSM). An SPI could be established which allows to store the secret in a predefined way in that sink. The sink could be as simple as a service which write crypted mails to the other party. The installation tab might show a link to the external system, which would enforce specific authorization requirements.

What do you think?

Mit freundlichen Grüßen / Best regards

Markus Till


> -----Ursprüngliche Nachricht-----
> Von: keyclo...@googlegroups.com <keyclo...@googlegroups.com> Im
> Auftrag von Marek Posolda
> Gesendet: Dienstag, 31. August 2021 16:51
> An: Keycloak Dev <keyclo...@googlegroups.com>
> Betreff: [keycloak-dev] Stop storing private keys of SAML clients in Keycloak DB

> --
> You received this message because you are subscribed to the Google Groups
> "Keycloak Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> keycloak-dev...@googlegroups.com.
> To view this discussion on the web visit
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google
> .com%2Fd%2Fmsgid%2Fkeycloak-dev%2F2ab24fd5-acec-e275-4162-
> e5b325e114fc%2540redhat.com&amp;data=04%7C01%7Cmarkus.till%40bosch.io%
> 7C01043b282b374392cc2308d96c8ebca4%7C0ae51e1907c84e4bbb6d648ee58410f
> 4%7C0%7C0%7C637660182569764398%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000
> &amp;sdata=qPsfaiXTsxIIPlGdba5%2BDQ6w9uL3O71FRZw20nkv3rg%3D&amp;re
> served=0.

[Marek Posolda]

This is interesting idea, however it seems it may take non-trivial
amount of work of implement something like this. Also the thing is, that
Keycloak doesn't need private key of the client and if there are these
options:
a) Keycloak doesn't have access to the private key of the client
b) Keycloak has access to the private key even if it is saved and
accessed in the very secured way
The option (a) is still safer IMO.

I see the only benefit of saving the private key in the Keycloak DB is
the improved usability due the "Installations" tab, which directly
contains the private key. However when there is a need to setup vault
solution for this, the usability benefit is gone (because setup of the
vault is more complicated than manually setup the private key in the
adapter configuration).

Marek