Keycloak on Docker using SAML2.0

Hi there,
I’m quite new over this world, I spent last time reading over all documentation I found on how to set up a (working) Keycloak standalone server deployed on Docker with MS ADFS through SAML 2.0.

Im following THIS guide, I’m stuck on to enabling HTTPS: I incounter difficulties because Keycloak is actually deployed in a Docker container. I generated the self signed certificate and I’m trying to access the CLI to create a new realm and add the certificate, but CLI is not available (as far as I know because Keycloak does not reside in the Host VM but in Docker) and also I cannot find the location of the standalone.xml to add it manually.
I guess there will by a completely Keycloak web interface procedure to do the same, but I cannot find it anywhere.

Probably it’s a stupid question related to my so bad level of Linux usage
Thanks for any advices or suggestions!


Publish port 8443 from the container and job is done -

Yes but this is not for a production environment, there is an exact procedure I followed in the guide (linked in the first post) the I assume should work as state-of-art approach. I was able at the moment to do all the modifications involved, so editing the right standalone.xml file, adding keystore and truststore (I did all the modification by building a modified version of keycloak for docker), but the point is still that I cannot run the https version. If I check the docker log keycloak is still expecting an application.keystore file to be loaded but that’s not what the guide asks me to do. Looks like it has not been taken into cosideration the new added security realm ‘UndertowRealm’.

Could you give me another piece of help on this?

OK, that is mindset from non container world. That guide and all Keycloak guides are also from that world. So you can spent your X man hours to follow guide and replicate it to the Docker world = build and manages own custom image. If you want that, then go ahead: inspect files in the running container and debug run scripts - they may interfere with your own configs.

But I never do that. I would read Docker image description first . There is section Setting up TLS(SSL). But unfortunately, it is not saying anything TLS port, so you will stuck again.

1 Like

Ok you opened me a completely new way, sorry but as you understood, I’m not docker minded, yet.

I restored the stock Keycloak image and I’m trying to run with your advices, In the image documentation it is stated:

Setting up TLS(SSL)

Keycloak image allows you to specify both a private key and a certificate for serving HTTPS. In that case you need to provide two files:

  • tls.crt - a certificate
  • tls.key - a private key

Those files need to be mounted in /etc/x509/https directory. The image will automatically convert them into a Java keystore and reconfigure Wildfly to use it. NOTE: When using volume mounts in containers the files will be mounted in the container as owned by root, as the default permission on the keyfile will most likely be 700 it will result in an empty keystore. You will either have to make the key world readable or extend the image to add the keys with the appropriate owner.

First thing is, where I have to mount .crt and .key files? is it correct in keycloak volume in the docker-compose file?

– ./tls.key:/etc/x509/https/tls.key
– ./tls.crt:/etc/x509/https/tls.crt

Second, what is trying to tell me with its NOTE? How I could fulfill that?

Third, I have to completely forgot of Keycloak guide or I have also to apply those steps?

Sorry for bothering you with stupids, lot of first times in this project

Yes, that’s correct. Of course you don’t need to follow naming convention in host OS:

      image: jboss/keycloak:11.0.2
        - /<path>/domain.crt:/etc/x509/https/tls.crt
        - /<path>/domain.key:/etc/x509/https/tls.key
        - 443:8443

Docker doc:

Note warns you that standard non docker knowledge that tls key must be owned/readable only for root is not correct here. That’s because another user uid is used for running keycloak in the container (usually uid 1000), so that user may not have permission to read that key. Quick fix will be chmod +r /<path>/domain.key

1 Like

I tried with that compose configuration, I applied the reading permission as you suggested, and updated ports as 443:8443. It allowed me to access now the application on https://mydomain/auth and this is obviously a success!
I have to check if the https://mydomain/auth/realms/myrealm/broker/adfs-idp-alias/endpoint/descriptor is accepted as relying party trust by the ADFS server.

My question is, how am I supposed to config Keycloak for the truststore certificate (the one coming from ADFS) to allow Keycloak to check if incoming https requests are trusty? In the guide I linked up there was a step in the procedure for this, but now that I’m following this procedure (that also seems to work, till now) how should I do that?
I want to remember that now I didn’t edit the standalone.xml at all, it’s the standard one, also the truststore is not loaded at all in Keycloak.

Thanks a lot!

Again from the Docker image readme:

It is also possible to provide an additional CA bundle and setup Mutual TLS this way. In that case, you need to mount an additional volume (or multiple volumes) to the image. These volumes should contain all necessary crt files. The final step is to configure the X509_CA_BUNDLE environment variable to contain a list of the locations of the various CA certificate bundle files specified before, separated by space ( `` ). In case of an OpenShift environment, that could be /var/run/secrets/ /var/run/secrets/ .

So env variable X509_CA_BUNDLE is the key. Eventually check the source code, there are also some examples:

Oh I thought this last procedure was only for 3rd part CA certificates from Keycloak side, anyway, not enough to thank, I applied it with:

    X509_CA_BUNDLE: /var/run/secrets/mycert.crt
    - ./tls.key:/etc/x509/https/tls.key
    - ./tls.crt:/etc/x509/https/tls.crt
    - ./mycert.crt:/var/run/secrets/mycert.crt

and the docker log answers:

Creating HTTPS keystore via OpenShift's service serving x509 certificate secrets..
HTTPS keystore successfully created at: /opt/jboss/keycloak/standalone/configuration/keystores/https-keystore.jks
Creating Keycloak truststore..
Keycloak truststore successfully created at: /opt/jboss/keycloak/standalone/configuration/keystores/truststore.jks
Warning: use -cacerts option to access cacerts keystore
Importing certificates from system's Java CA certificate bundle into Keycloak truststore..
Successfully imported certificates from system's Java CA certificate bundle into Keycloak truststore at: /opt/jboss/keycloak/standalone/configuration/keystores/truststore.jks

So I assume everything went well, thenI tried to finally add Keycloak as relying party trust in ADFS Server , using this URL:


(Opening it over browser shows me an XML )

and had :

Tried then loading the .xml file of the URL and it has been accepted!

Then I created the 3 claims that the guide suggests, and now I’m trying to login with an ADFS credential into my application (on top of Keycloak) but It answers with wrong credentials. I don’t know actually if I have to apply some configurations between Keycloak and my application (It has not being built by me obviously). I wonder if there is a way to check only using Keycloak and ADFS server the login functionality without passing through the application, to check if at least this communication works, and then investigate what measures are needed to let the application correctly orchestrate with keycloak.

Do you have, still, any suggestions?

I know that my question is truly generic, I will try to tighten the range, this is the SAML response in keycloak log when I access a user that is on ADFS:

10:06:25,754 WARN  [] (default task-5) type=LOGIN_ERROR, realmId=xxx, clientId=xxx, userId=null, ipAddress=xxx, error=user_not_found, auth_method=openid-connect, grant_type=password, client_auth_method=client-secret, username='xxx', authSessionParentId=xxx, authSessionTabId=xxx

Is it normal that it states “auth_method=openid-connect” ?

Thank you