Installation and Configuration of Keycloak Server

Configuring the Server Although the Keycloak Server is designed to run out of the box, there's some things you'll need to configure before you go into production. Specifically: Configuring Keycloak to use a production database Setting up SSL/HTTPS Enforcing HTTPS connections

Admin User To access the admin console to configure Keycloak you need an account to login. There is no built in user, instead you have to first create an admin account. This can done either by opening http://localhost:8080/auth (creating a user through the browser can only be done through localhost) or you can use the add-user script from the command-line. The add-user script creates a temporary file with the details of the user, which are imported at startup. To add a user with this script run: -p ]]> Then restart the server. For keycloak-overlay, please make sure to use: -p ]]>

Relational Database Configuration You might want to use a better relational database for Keycloak like PostgreSQL or MySQL. You might also want to tweak the configuration settings of the datasource. Please see the Wildfly documentation on how to do this. Keycloak runs on a Hibernate/JPA backend which is configured in the standalone/configuration/keycloak-server.json. By default the setting is like this: Possible configuration options are: dataSource JNDI name of the dataSource jta boolean property to specify if datasource is JTA capable driverDialect Value of Hibernate dialect. In most cases you don't need to specify this property as dialect will be autodetected by Hibernate. databaseSchema Specify if schema should be updated or validated. Valid values are "update" and "validate" ("update is default). showSql Specify whether Hibernate should show all SQL commands in the console (false by default) formatSql Specify whether Hibernate should format SQL commands (true by default) schema Specify the database schema to use

Tested databases Here is list of RDBMS databases and corresponding JDBC drivers, which were tested with Keycloak. Note that Hibernate dialect is usually set automatically according to your database, but in some cases, you must manually set the proper dialect, as the default dialect may not work correctly. You can setup dialect by adding property driverDialect to the keycloak-server.json into connectionsJpa section (see above). Tested databases Database JDBC driver Hibernate Dialect H2 1.3.161 H2 1.3.161 auto MySQL 5.5 MySQL Connector/J 5.1.25 auto PostgreSQL 9.2 JDBC4 Postgresql Driver, Version 9.3-1100 auto PostgresPlus 9.4 edb-jdbc17-4.0 auto Oracle 11g R1 Oracle JDBC Driver v11.1.0.7 auto Microsoft SQL Server 2012 Microsoft SQL Server JDBC Driver 4.0.2206.100 org.hibernate.dialect.SQLServer2008Dialect IBM DB2 10.5 JDBC 4.0 Driver (db2jcc4.jar) 4.19.26 auto

MongoDB based model Keycloak provides MongoDB based model implementation, which means that your identity data will be saved in MongoDB instead of traditional RDBMS. To configure Keycloak to use Mongo open standalone/configuration/keycloak-server.json in your favourite editor, then change: to: And at the end of the file add the snippet like this where you can configure details about your Mongo database: All configuration options are optional. Default values for host and port are localhost and 27017. Default name of database is keycloak . You can also specify properties user and password if you want authenticate against your MongoDB. If user and password are not specified, Keycloak will connect unauthenticated to your MongoDB. Finally there is set of optional configuration options, which can be used to specify connection-pooling capabilities of Mongo client. Supported int options are: connectionsPerHost, threadsAllowedToBlockForConnectionMultiplier, maxWaitTime, connectTimeout socketTimeout. Supported boolean options are: socketKeepAlive, autoConnectRetry. Supported long option is maxAutoConnectRetryTime. See Mongo documentation for details about those options and their default values. Alternatively, you can configure MongoDB using a MongoDB connection URI. In this case, you define all information concerning the connection and authentication within the URI, as described in the MongoDB documentation. Please note that the database specified within the URI is only used for authentication. To change the database used by keycloak you have to set db property as before. Therefore, a configuration like the following will authenticate the user against the authentication database, but store all keycloak related data in the keycloak database.

MongoDB Replica Sets In order to use a mongo replica set for Keycloak, one has to use URI based configuration, which supports the definition of replica sets out of the box: mongodb://host1:27017,host2:27017,host3:27017/.

Outgoing Server HTTP Requests Keycloak server needs to invoke on remote HTTP endpoints to do things like backchannel logouts and other management functions. Keycloak maintains a HTTP client connection pool which has various configuration settings you can specify before boot time. This is configured in the standalone/configuration/keycloak-server.json. By default the setting is like this: Possible configuration options are: establish-connection-timeout-millis Timeout for establishing a socket connection. socket-timeout-millis If an outgoing request does not receive data for this amount of time, timeout the connection. connection-pool-size How many connections can be in the pool (128 by default). max-pooled-per-route How many connections can be pooled per host (64 by default). connection-ttl-millis Maximum connection time to live in milliseconds. Not set by default. max-connection-idle-time-millis Maximum time the connection might stay idle in the connection pool (900 seconds by default). Will start background cleaner thread of Apache HTTP client. Set to -1 to disable this checking and the background thread. disable-cookies true by default. When set to true, this will disable any cookie caching. client-keystore This is the file path to a Java keystore file. This keystore contains client certificate for two-way SSL. client-keystore-password Password for the client keystore. This is REQUIRED if client-keystore is set. client-key-password Not supported yet, but we will support in future versions. Password for the client's key. This is REQUIRED if client-keystore is set.

Securing Outgoing Server HTTP Requests When Keycloak connects out to remote HTTP endpoints over secure https connection, it has to validate the other server's certificate in order to ensure it is connecting to a trusted server. That is necessary in order to prevent man-in-the-middle attacks. How certificates are validated is configured in the standalone/configuration/keycloak-server.json. By default truststore provider is not configured, and any https connections fall back to standard java truststore configuration as described in Java's JSSE Reference Guide - using javax.net.ssl.trustStore system property, otherwise cacerts file that comes with java is used. Truststore is used when connecting securely to identity brokers, LDAP identity providers, when sending emails, and for backchannel communication with client applications. Some of these facilities may - in case when no trusted certificate is found in your configured truststore - fallback to using the JSSE provided truststore. The default JavaMail API implementation used to send out emails behaves in this way, for example. You can add your truststore configuration by using the following template: Possible configuration options are: file The value is the file path to a Java keystore file. HTTPS requests need a way to verify the host of the server they are talking to. This is what the trustore does. The keystore contains one or more trusted host certificates or certificate authorities. Truststore file should only contain public certificates of your secured hosts. This is REQUIRED if disabled is not true. password Password for the truststore. This is REQUIRED if disabled is not true. hostname-verification-policy WILDCARD by default. For HTTPS requests, this verifies the hostname of the server's certificate. ANY means that the hostname is not verified. WILDCARD Allows wildcards in subdomain names i.e. *.foo.com. STRICT CN must match hostname exactly. disabled If true (default value), truststore configuration will be ignored, and certificate checking will fall back to JSSE configuration as described. If set to false, you must configure file, and password for the truststore. You can use keytool to create a new truststore file and add trusted host certificates to it: $ keytool -import -alias HOSTDOMAIN -keystore truststore.jks -file host-certificate.cer

SSL/HTTPS Requirement/Modes Keycloak is not set up by default to handle SSL/HTTPS. It is highly recommended that you either enable SSL on the Keycloak server itself or on a reverse proxy in front of the Keycloak server. Keycloak can run out of the box without SSL so long as you stick to private IP addresses like localhost, 127.0.0.1, 10.0.x.x, 192.168.x.x, and 172..16.x.x. If you try to access Keycloak from a non-IP adress you will get an error. Keycloak has 3 SSL/HTTPS modes which you can set up in the admin console under the Settings->Login page and the Require SSL select box. Each adapter config should mirror this server-side setting. See adapter config section for more details. external Keycloak can run out of the box without SSL so long as you stick to private IP addresses like localhost, 127.0.0.1, 10.0.x.x, 192.168.x.x, and 172..16.x.x. If you try to access Keycloak from a non-IP adress you will get an error. none Keycloak does not require SSL. all Keycloak requires SSL for all IP addresses.

SSL/HTTPS Setup First enable SSL on Keycloak or on a reverse proxy in front of Keycloak. Then configure the Keycloak Server to enforce HTTPS connections.

Enable SSL on Keycloak The following things need to be done Generate a self signed or third-party signed certificate and import it into a Java keystore using keytool. Enable Wildfly to use this certificate and turn on SSL/HTTPS.

Creating the Certificate and Java Keystore In order to allow HTTPS connections, you need to obtain a self signed or third-party signed certificate and import it into a Java keystore before you can enable HTTPS in the web container you are deploying the Keycloak Server to.

Self Signed Certificate In development, you will probably not have a third party signed certificate available to test a Keycloak deployment so you'll need to generate a self-signed on. Generate one is very easy to do with the keytool utility that comes with the Java jdk. $ keytool -genkey -alias localhost -keyalg RSA -keystore keycloak.jks -validity 10950 Enter keystore password: secret Re-enter new password: secret What is your first and last name? [Unknown]: localhost What is the name of your organizational unit? [Unknown]: Keycloak What is the name of your organization? [Unknown]: Red Hat What is the name of your City or Locality? [Unknown]: Westford What is the name of your State or Province? [Unknown]: MA What is the two-letter country code for this unit? [Unknown]: US Is CN=localhost, OU=Keycloak, O=Test, L=Westford, ST=MA, C=US correct? [no]: yes You should answer What is your first and last name ? question with the DNS name of the machine you're installing the server on. For testing purposes, localhost should be used. After executing this command, the keycloak.jks file will be generated in the same directory as you executed the keytool command in. If you want a third-party signed certificate, but don't have one, you can obtain one for free at cacert.org. You'll have to do a little set up first before doing this though. The first thing to do is generate a Certificate Request: $ keytool -certreq -alias yourdomain -keystore keycloak.jks > keycloak.careq Where yourdomain is a DNS name for which this certificate is generated for. Keytool generates the request: -----BEGIN NEW CERTIFICATE REQUEST----- MIIC2jCCAcICAQAwZTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAk1BMREwDwYDVQQHEwhXZXN0Zm9y ZDEQMA4GA1UEChMHUmVkIEhhdDEQMA4GA1UECxMHUmVkIEhhdDESMBAGA1UEAxMJbG9jYWxob3N0 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr7kck2TaavlEOGbcpi9c0rncY4HhdzmY Ax2nZfq1eZEaIPqI5aTxwQZzzLDK9qbeAd8Ji79HzSqnRDxNYaZu7mAYhFKHgixsolE3o5Yfzbw1 29Rvy+eUVe+WZxv5oo9wolVVpdSINIMEL2LaFhtX/c1dqiqYVpfnvFshZQaIg2nL8juzZcBjj4as H98gIS7khql/dkZKsw9NLvyxgJvp7PaXurX29fNf3ihG+oFrL22oFyV54BWWxXCKU/GPn61EGZGw Ft2qSIGLdctpMD1aJR2bcnlhEjZKDksjQZoQ5YMXaAGkcYkG6QkgrocDE2YXDbi7GIdf9MegVJ35 2DQMpwIDAQABoDAwLgYJKoZIhvcNAQkOMSEwHzAdBgNVHQ4EFgQUQwlZJBA+fjiDdiVzaO9vrE/i n2swDQYJKoZIhvcNAQELBQADggEBAC5FRvMkhal3q86tHPBYWBuTtmcSjs4qUm6V6f63frhveWHf PzRrI1xH272XUIeBk0gtzWo0nNZnf0mMCtUBbHhhDcG82xolikfqibZijoQZCiGiedVjHJFtniDQ 9bMDUOXEMQ7gHZg5q6mJfNG9MbMpQaUVEEFvfGEQQxbiFK7hRWU8S23/d80e8nExgQxdJWJ6vd0X MzzFK6j4Dj55bJVuM7GFmfdNC52pNOD5vYe47Aqh8oajHX9XTycVtPXl45rrWAH33ftbrS8SrZ2S vqIFQeuLL3BaHwpl3t7j2lMWcK1p80laAxEASib/fAwrRHpLHBXRcq6uALUOZl4Alt8= -----END NEW CERTIFICATE REQUEST----- Send this ca request to your CA. The CA will issue you a signed certificate and send it to you. Before you import your new cert, you must obtain and import the root certificate of the CA. You can download the cert from CA (ie.: root.crt) and import as follows: $ keytool -import -keystore keycloak.jks -file root.crt -alias root Last step is import your new CA generated certificate to your keystore: $ keytool -import -alias yourdomain -keystore keycloak.jks -file your-certificate.cer

Installing the keystore to WildFly Now that you have a Java keystore with the appropriate certificates, you need to configure your Wildfly installation to use it. First step is to move the keystore file to a directory you can reference in configuration. I like to put it in standalone/configuration. Then you need to edit standalone/configuration/standalone.xml to enable SSL/HTTPS. To the security-realms element add: ]]> Find the element <server name="default-server"> (it's a child element of <subsystem xmlns="urn:jboss:domain:undertow:1.0">) and add: ]]> Check the Wildfly Undertow documentation for more information on fine tuning the socket connections.

Enable SSL on a Reverse Proxy Follow the documentation for your web server to enable SSL and configure reverse proxy for Keycloak. It is important that you make sure the web server sets the X-Forwarded-For and X-Forwarded-Proto headers on the requests made to Keycloak. Next you need to enable proxy-address-forwarding on the Keycloak http connector. Assuming that your reverse proxy doesn't use port 8443 for SSL you also need to configure what port http traffic is redirected to.

Configure WildFly Open standalone/configuration/standalone.xml in your favorite editor. First add proxy-address-forwarding and redirect-socket to the http-listener element: ... ... ]]> Then add a new socket-binding element to the socket-binding-group element: ... ... ]]> Check the WildFly documentation for more information.