diff --git a/docbook/pom.xml b/docbook/pom.xml
new file mode 100755
index 0000000000..b8625dbcc0
--- /dev/null
+++ b/docbook/pom.xml
@@ -0,0 +1,119 @@
+
+
+ 4.0.0
+
+ org.keycloak
+ keycloak-reference-guide-${translation}
+ 1.0-alpha-1-SNAPSHOT
+ jdocbook
+ Keycloak Reference Guide (${translation})
+
+
+
+ jboss
+ http://repository.jboss.org/nexus/content/groups/public/
+
+
+
+
+
+ jboss
+ http://repository.jboss.org/nexus/content/groups/public/
+
+
+
+
+
+
+
+ org.jboss.maven.plugins
+ maven-jdocbook-plugin
+ 2.3.8
+ true
+
+
+
+ org.jboss.pressgang
+ pressgang-xslt-ns
+ 2.0.2
+
+
+ org.jboss.pressgang
+ pressgang-jdocbook-style
+ jdocbook-style
+ 2.0.2
+
+
+
+
+ master.xml
+ en-US
+ reference/en
+
+ reference/en
+
+ images/*
+
+
+
+
+ html_single
+ classpath:/xslt/org/jboss/xhtml-single.xsl
+ index.html
+
+
+
+ html
+ classpath:/xslt/org/jboss/xhtml.xsl
+ index.html
+
+
+
+ pdf
+ classpath:/xslt/org/jboss/pdf.xsl
+ ${project.artifactId}.pdf
+
+
+
+
+
+
+
+
+
+ project.version
+ ${project.version}
+
+
+
+ saxon
+ true
+ true
+
+ 1.72.0
+
+
+
+
+
+
+
+
+ en-US
+
+
diff --git a/docbook/reference/en/en-US/master.xml b/docbook/reference/en/en-US/master.xml
new file mode 100755
index 0000000000..a984d7d73b
--- /dev/null
+++ b/docbook/reference/en/en-US/master.xml
@@ -0,0 +1,59 @@
+
+
+
+
+
+
+ ]>
+
+
+
+
+ Keycloak Reference Guide
+ SSO for Web Apps and REST Services
+ 1.0-alpha-1-SNAPSHOT
+
+
+
+
+
+ Preface
+
+ In some of the example listings, what is meant to be displayed on one line does not fit
+ inside the available page width. These lines have been broken up. A '\' at the end of a
+ line means that a break has been introduced to fit in the page, with the following lines
+ indented. So:
+
+ Let's pretend to have an extremely \
+ long line that \
+ does not fit
+ This one is short
+
+ Is really:
+
+ Let's pretend to have an extremely long line that does not fit
+ This one is short
+
+
+
+
+ &License;
+ &Overview;
+ &Installation;
+
+ Adapters
+
+ Keycloak can secure a wide variety of application types. This section defines which application
+ types are supported and how to configure and install them so that you can use Keycloak to secure
+ your applications.
+
+ &AdapterConfig;
+ &WildflyAdapter;
+ &EAP6Adapter;
+
+
+
+
diff --git a/docbook/reference/en/en-US/modules/License.xml b/docbook/reference/en/en-US/modules/License.xml
new file mode 100755
index 0000000000..eb7095bd17
--- /dev/null
+++ b/docbook/reference/en/en-US/modules/License.xml
@@ -0,0 +1,7 @@
+
+ License
+ RESTEasy is distributed under the ASL 2.0 license. It does not distribute any thirdparty libraries that are
+ GPL. It does ship thirdparty libraries licensed under
+ Apache ASL 2.0 and LGPL.
+
+
diff --git a/docbook/reference/en/en-US/modules/Overview.xml b/docbook/reference/en/en-US/modules/Overview.xml
new file mode 100755
index 0000000000..a542da871d
--- /dev/null
+++ b/docbook/reference/en/en-US/modules/Overview.xml
@@ -0,0 +1,127 @@
+
+ Overview
+
+
+ Keycloak is an SSO solution for web apps and RESTful web services. It is an authentication server where users
+ can centrally login, logout, register, and manage their user accounts. The Keycloak admin UI can manage roles
+ and role mappings for any application secured by Keycloak. The Keycloak Server can also be used to perform
+ social logins via the user's favorite social media site i.e. Google, Facebook, Twitter etc.
+
+
+
+
+
+
+ Features:
+
+
+
+ SSO and Single Log Out for browser applications
+
+
+
+ Social Broker. Enable Google, Facebook, Yahoo, Twitter social login with no code required.
+
+
+
+ Optional User Registration
+
+
+
+ Password and TOTP support (via Google Authenticator). Client cert auth coming soon.
+
+
+
+ OAuth Bearer token auth for REST Services
+
+
+
+ Integrated Browser App to REST Service token propagation
+
+
+ OAuth Bearer token auth for REST Services
+
+
+ OAuth 2.0 Grant requests
+
+
+ CORS Support
+
+
+ CORS Web Origin management and validation
+
+
+ Completely centrally managed user and role mapping metadata. Minimal configuration at the application side
+
+
+ Admin Console for managing users, roles, role mappings, applications, user sessions, allowed CORS web origins, and OAuth clients.
+
+
+ Deployable as a WAR, appliance, or on Openshift.
+
+
+ Supports JBoss AS7, EAP 6.x, and Wildfly applications. Plans to support Node.js, RAILS, GRAILS, and other non-Java application
+
+
+
+
+ Key Concepts in Keycloak
+
+ The core concept in Keycloak is a Realm. A realm secures and manages security metadata for
+ for a set of users, applications, and registered oauth clients. Users can be created within a specific realm
+ within the Administration console. Roles (permission types) can be defined at the realm level and you can also
+ set up user role mappings to assign these permissions to specific users.
+
+
+ An application is a service that is secured by a realm. When a user browses an
+ application's web site, the application can redirect the user agent to the Keycloak Server and request a login.
+ Once a user is logged in, they can visit any other application managed by the realm and not have to re-enter
+ credentials. This also hold true for logging out. Roles can also be defined at the application level and
+ assigned to specific users. Depending on the application type, you may also be able to view and manage
+ user sessions from the adminstration console.
+
+
+ An oauth client is similar to an application in that it can request something like a login
+ when a user visits the site of the oauth client. The difference is that oauth clients are not immediately granted
+ all permissions of the user. In addition to requesting the login credentials of the user, the Keycloak Server
+ will also display a grant page asking the user if it is ok to grant allowed permissions to the oauth client.
+
+
+
+ How Does Security Work in Keycloak?
+
+ Keycloak uses access tokens. Access tokens are contains security metadata specifying the
+ identity of the user as well as the role mappings for that user. The format of these tokens is a Keycloak
+ extension to the JSON Web Token specification. Each realm has a private and public key pair
+ which it uses to digitally sign the access token using the JSON Web Signature specification.
+ Applications can verify the integrity of the digitally signed
+ access token using the public key of the realm. The protocols used to obtain this token is defined by the
+ OAuth 2.0 specification.
+
+
+ The interesting thing about using these smart access tokens is that applications themselves are completely stateless
+ as far as security metadata goes. All the information they need about the user is contained in the token and there's
+ no need for them to store any security metadata locally other than the public key of the realm.
+
+
+ Signed access tokens can also be proprogated by REST client requests within an Authorization
+ header. This is great for distributed integration as applications can request a login from a client to obtain
+ an access token, then invoke any aggregated REST invocations to other services using that access token. So,
+ you have a distributed security model that is centrally managed, yet does not require a Keycloak Server hit
+ per request, only for the initial login.
+
+
+ Permission Scopes
+
+ Each application and oauth client are configured with a set of permission scopes. These are a set
+ of roles that an application or oauth client is allowed to ask permission for. Access tokens are always
+ granted at the request of a specific application or oauth client. This also holds true for SSO. As you visit
+ different sites, the application will redirect back to the Keycloak Server via the OAuth 2.0 protocol to obtain an access
+ token specific to that application. The role mappings contained within the token are the union
+ between the set of user role mappings and the permission scope of the application/oauth client. So,
+ access tokens are tailor made for each application/oauth client and contain only the information required
+ for by them.
+
+
+
+
diff --git a/docbook/reference/en/en-US/modules/adapter-config.xml b/docbook/reference/en/en-US/modules/adapter-config.xml
new file mode 100755
index 0000000000..8f4ed9c28c
--- /dev/null
+++ b/docbook/reference/en/en-US/modules/adapter-config.xml
@@ -0,0 +1,273 @@
+
+ General Adapter Config
+
+ Each adapter supported by Keycloak can be configured by a simple JSON text file. This is what one might
+ look like:
+
+
+
+
+
+
+
+ Some of these configuration switches may be adapter specific and some are common across all adapters.
+ For Java adapters you can use ${...} enclosure as System property replacement.
+ For example ${jboss.server.config.dir}. Also, you can obtain a template
+ for this config file from the admin console. Go to the realm and application you want a template for.
+ Go to the Installation tab and this will provide you with a template that includes
+ the public key of the realm.
+
+
+ Here is a description of each item:
+
+
+
+
+ realm
+
+
+ Name of the realm representing the users of your distributed applications and services.
+ This is
+ REQUIRED.
+
+
+
+
+ resource
+
+
+ Username of the application. Each application has a username that is used when the
+ application connects with the Keycloak server to turn an access code into an access token
+ (part of the OAuth 2.0 protocol). This is
+ REQUIRED.
+
+
+
+
+ realm-public-key
+
+
+ PEM format of public key. You can obtain this from the administration console.
+ This is
+ REQUIRED.
+
+
+
+
+ auth-url
+
+
+ URL of the realm's login page of the Keycloak Server's token service. You can obtain
+ this URL from the admin console.
+ This is
+ REQUIRED.
+
+
+
+
+ code-url
+
+
+ URL to turn an access code into an access token. You can obtain
+ this URL from the admin console.
+ This is
+ REQUIRED.
+
+
+
+
+ ssl-not-required
+
+
+ Ensures that all communication to and from the Keycloak server from the adapter is over HTTPS.
+ This isOPTIONAL. The default value is
+ false
+ meaning
+ that HTTPS is required by default.
+
+
+
+
+ user-resource-role-mappings
+
+
+ If set to true, the adapter will look inside the token for application level role mappings for
+ the
+ user. If false, it will look at the realm level for user role mappings.
+ This isOPTIONAL. The default value isfalse.
+
+
+
+
+ enable-cors
+
+
+ This enables CORS support. It will handle CORS preflight requests. It will also look into
+ the access token to determine valid origins.
+ This isOPTIONAL. The default value isfalse.
+
+
+
+
+ cors-max-age
+
+
+ If CORS is enabled, this sets the value of the
+ Access-Control-Max-Age
+ header.
+ This isOPTIONAL. If not set, this header is not returned in CORS
+ responses.
+
+
+
+
+ cors-allowed-methods
+
+
+ If CORS is enabled, this sets the value of the
+ Access-Control-Allow-Methods
+ header. This should be a JSON list of strings.
+ This isOPTIONAL. If not set, this header is not returned in CORS
+ responses.
+
+
+
+
+ bearer-only
+
+
+ This tells the adapter to only to bearer token authentication. That is, it will not do
+ OAuth 2.0 redirects, but only accept bearer tokens through the
+ Authorization
+ header.
+ This isOPTIONAL. The default value isfalse.
+
+
+
+
+ expose-token
+
+
+ Iftrue, an authenticated browser client (via a Javascript HTTP invocation)
+ can obtain the signed access token via the URLroot/K_QUERY_BEARER_TOKEN.
+ This isOPTIONAL. The default value isfalse.
+
+
+
+
+ credentials
+
+
+ Specify the credentials of the application. This is an object notation where the key
+ is the credential type and the value if the value of the credential type. Currently only
+ password
+ is supported.
+ This isREQUIRED.
+
+
+
+
+ truststore
+
+
+ This setting is for Java adapters. This is the file path to a Java keystore file.
+ Used for outgoing HTTPS communications to the Keycloak server. Client making 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. You can
+ create this truststore by extracting the public certificate of the Keycloak server's SSL
+ keystore.
+ This is
+ OPTIONAL
+ if
+ ssl-not-required
+ is
+ false
+ or
+ disable-trust-manager
+ istrue. The default value isfalse.
+
+
+
+
+ truststore-password
+
+
+ Password for the truststore keystore.
+ This is
+ REQUIRED
+ if
+ truststore
+ is set.
+
+
+
+
+ client-keystore
+
+
+ Not supported yet, but we will support in future versions.
+
+ This setting is for Java adapters. This is the file path to a Java keystore file.
+ This keystore contains client certificate for two-way SSL when the adapter makes
+ HTTPS requests to the Keycloak server.
+ This isOPTIONAL.
+
+
+
+
+ client-keystore-password
+
+
+ Not supported yet, but we will support in future versions.
+ 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.
+
+
+
+
+
+
\ No newline at end of file
diff --git a/docbook/reference/en/en-US/modules/eap6-adapter.xml b/docbook/reference/en/en-US/modules/eap6-adapter.xml
new file mode 100755
index 0000000000..88ec08025a
--- /dev/null
+++ b/docbook/reference/en/en-US/modules/eap6-adapter.xml
@@ -0,0 +1,116 @@
+
+ JBoss EAP6/AS7 Adapter
+
+ JBoss EAP6/AS7 Adapter Adapter Installation
+
+ The JBoss EAP6 Adapter is contained in the Keycloak distribution within the adapters/keycloak-eap6-adapter-dist.zip
+ file. Conversely, the JBoss AS 7.1.1 adapter is contained in the file adapters/keycloak-as7-adapter-dist.zip
+ To install it:
+
+
+
+ $ cd $JBOSS_HOME
+ # For an EAP distro
+ $ unzip keycloak-eap6-adapter-dist.zip
+
+ or
+ # For an JBoss AS 7.1.1 distro
+ $ unzip keycloak-as7-adapter-dist.zip
+
+
+
+ This zip file creates new JBoss Modules specific to the JBoss EAP6 Keycloak Adapter within your JBoss distro.
+
+
+
+ JBoss EAP6/AS7 Adapter Configuration
+
+ The JBoss EAP6 Adapter is enabled per WAR application. The adapter code is contained in a JBoss Module
+ so you must first create a jboss-deployment-structure.xml within your WAR's
+ WEB-INF directory that imports the JBoss EAP6 Keycloak Adapter.
+
+
+
+
+
+
+
+
+]]>
+
+
+
+ It is possible to add the adapter jars directory to your WAR, but its best to do module imports because
+ the adapter's dependencies may conflict with your application's.
+
+
+ After creating the jboss-deployment-structure.xml configuration file, you must create
+ a keycloak.json adapter config file within the WEB-INF directory
+ of your WAR. The format of this config file is describe in the general adapter configuration
+ section.
+
+
+ While you do have to specify a login-config in your WAR's web.xml, it doesn't matter what values you put there.
+ You also
+ have to use standard servlet security to specify role-base constraints on your URLs. Here's an example
+ pulled from one of the examples that comes distributed with Keycloak.
+
+
+
+
+
+
+ customer-portal
+
+
+
+ Admins
+ /admin/*
+
+
+ admin
+
+
+
+
+ Customers
+ /customers/*
+
+
+ user
+
+
+
+
+
+
+ BASIC
+ commerce
+
+
+
+ admin
+
+
+ user
+
+
+]]>
+
+
+ ]
+
+
\ No newline at end of file
diff --git a/docbook/reference/en/en-US/modules/server-installation.xml b/docbook/reference/en/en-US/modules/server-installation.xml
new file mode 100755
index 0000000000..749f24648a
--- /dev/null
+++ b/docbook/reference/en/en-US/modules/server-installation.xml
@@ -0,0 +1,369 @@
+
+ Installation and Configuration of Keycloak Server
+
+
+ The Keycloak Server has two downloadable distributions.
+
+
+
+
+
+ keycloak-appliance-dist-all-1.0-alpha-1-SNAPSHOT.zip
+
+
+
+ keycloak-war-dist-all-1.0-alpha-1-SNAPSHOT.zip
+
+
+
+
+
+
+ Appliance Install
+
+ The
+ keycloak-appliance-dist-all.zip
+ is quite large, but contains a complete server (backed by Wildfly)
+ that runs out of the box. The only thing you'll have to enable and configure is SSL. Unzipping it, the
+ directory layout looks
+ something like this:
+
+
+
+
+keycloak-appliance-dist-all-1.0-alpha-1-SNAPSHOT/
+ keycloak/
+ bin/
+ standalone.sh
+ standalone.bat
+ standalone/deployments/
+ auth-server.war/
+ keycloak-ds.xml
+
+ adapters/
+ keycloak-as7-adapter-dist-1.0-alpha-1-SNAPSHOT.zip
+ keycloak-as7-adapter-dist-1.0-alpha-1-SNAPSHOT.zip
+ keycloak-as7-adapter-dist-1.0-alpha-1-SNAPSHOT.zip
+ examples/
+ docs/
+
+
+
+ The
+ standalone.sh
+ or
+ standalone.bat
+ script is used to start the server.
+ After executing that, log into the admin console at
+ http://localhost:8080/auth-server/rest/saas/login.
+ Username:
+ admin
+ Password:admin. Keycloak with then prompt you to
+ enter in a new password.
+
+
+
+ WAR Distribution Installation
+
+ The
+ keycloak-war-dist-all.zip
+ contains
+ just the bits you need to install keycloak on your favorite web container. We currently only support
+ installing it on top of an existing JBoss AS 7.1.1, JBoss EAP 6.x, or Wildfly 8 distribution. We may in the
+ future provide directions on how to install it on another web container like Tomcat or Jetty. If anybody
+ in the community is interested in pulling this together, please contact us. Its mostly Maven pom work.
+
+
+ The directory structure of this distro looks like this:
+
+
+
+keycloak-war-dist-all-1.0-alpha-1-SNAPSHOT/
+ deployments/
+ auth-server.war/
+ keycloak-ds.xml
+ adapters/
+ keycloak-as7-adapter-dist-1.0-alpha-1-SNAPSHOT.zip
+ keycloak-as7-adapter-dist-1.0-alpha-1-SNAPSHOT.zip
+ keycloak-as7-adapter-dist-1.0-alpha-1-SNAPSHOT.zip
+ examples/
+ docs/
+
+
+
+ After unzipping this file, copy the deployments/ directory into to the standalone/
+ of your JBoss or Wildfly distro.
+
+
+
+ $ cd keycloak-war-dist-all-1.0-alpha-1-SNAPSHOT
+ $ cp -r deployments $JBOSS_HOME/standalone
+
+
+
+ After booting up the JBoss or Wildfly distro, you can then make sure it is installed properly
+ by logging into the admin console at
+ http://localhost:8080/auth-server/rest/saas/login.
+ Username:
+ admin
+ Password:admin. Keycloak with then prompt you to
+ enter in a new password.
+
+
+
+ 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
+
+
+
+
+ Database Configuration
+
+ The datasource used to store Keycloak data is configured in the .../standalone/deployments/keycloak-ds.xml
+ file of your Keycloak Server installation. A good thing to delete this file and move its configuration text into the
+ centrally managed .../standalone/configuration/standalone.xml file. This will allow
+ you to manage the database connection pool from the Wildfly/JBoss adminstration console. Here's what
+ .../standalone/configuration/standalone.xml should look like after you've done this:
+
+
+
+
+
+ jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE
+ h2
+
+ sa
+ sa
+
+
+
+ jdbc:h2:${jboss.server.data.dir}/keycloak;AUTO_SERVER=TRUE
+ h2
+
+ sa
+ sa
+
+
+
+
+ org.h2.jdbcx.JdbcDataSource
+
+
+
+
+]]>
+
+
+
+ Besides moving the database config into the central standalone.xml configuration file
+ you might want to use a better relational database for Keycloak like Oracle or something. You might also
+ want to tweak the configuration settings of the datasource. Please see the Wildfly,
+ JBoss AS7,
+ or JBoss EAP 6.x documentation on how to do this.
+
+
+ Keycloak also runs on a Hibernate/JPA backend which is configured in the
+ .../standalone/deployments/auth-server.war/WEB-INF/classes/META-INF/persistence.xml.
+ Please see the Hibernate and JPA documentation for more information on tweaking the backend datamodel.
+
+
+
+ SSL/HTTPS Setup
+
+
+ Keycloak is not set up by default to handle SSL/HTTPS in either the
+ war distribution or appliance. It is highly recommended that you enable it!
+
+
+
+ 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 JBoss or Wildfly to use this certificate and turn on SSL/HTTPS.
+
+
+
+ Configure the Keycloak Server to enforce HTTPS connections.
+
+
+
+
+ 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 the 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
+
+ Now that you have a Java keystore with the appropriate certificates, you need to configure your
+ JBoss or 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.
+
+
+
+
+
+
+
+ ...
+
+]]>
+
+
+
+ Check the Wildfly
+ or JBoss documentation for more information on fine tuning the socket connections.
+
+
+
+ Enforce HTTPS For Server Connections
+
+ Servlet containers can force browsers and other HTTP clients to use HTTPS. You have to configure this in
+ .../standalone/deployments/auth-server.war/WEB-INF/web.xml. All you have to do is
+ uncomment out the security constraint.
+
+
+
+ ...
+
+
+ /*
+
+
+ CONFIDENTIAL
+
+
+
+]]>
+
+
+
+
+ Enforce HTTPS at Realm Level
+
+ In Keycloak, each realm has an "Require SSL" switch that you should turn on. Log into the
+ adminstration console and set this switch for each realm that Keycloak manages. This switch is on
+ the Settings>>General page. While this switch does do similar checks as the security
+ constraint in web.xml, it will also force applications and oauth clients to only
+ register HTTPS based redirect URLs.
+
+
+
+
+
+
diff --git a/docbook/reference/en/en-US/modules/wildfly-adapter.xml b/docbook/reference/en/en-US/modules/wildfly-adapter.xml
new file mode 100755
index 0000000000..c1ca5ecd8f
--- /dev/null
+++ b/docbook/reference/en/en-US/modules/wildfly-adapter.xml
@@ -0,0 +1,107 @@
+
+ Wildfly 8 Adapter
+
+ Wildfly Adapter Installation
+
+ The Wildfly 8 Adapter is contained in the Keycloak distribution within the adapters/keycloak-wildfly-adapter-dist.zip
+ file. To install it:
+
+
+
+ $ cd $WILDFLY_HOME
+ $ unzip keycloak-wildfly-adapter-dist.zip
+
+
+
+ This zip file creates new JBoss Modules specific to the Wildfly Keycloak Adapter within your Wildfly distro.
+
+
+
+ Wildfly 8 Adapter Configuration
+
+ The Wildfly 8 Adapter is enabled per WAR application. The adapter code is contained in a JBoss Module
+ so you must first create a jboss-deployment-structure.xml within your WAR's
+ WEB-INF directory that imports the Wildfly Keycloak Adapter.
+
+
+
+
+
+
+
+
+]]>
+
+
+
+ It is possible to add the adapter jars directory to your WAR, but its best to do module imports because
+ the adapter's dependencies may conflict with your application's.
+
+
+ After creating the jboss-deployment-structure.xml configuration file, you must create
+ a keycloak.json adapter config file within the WEB-INF directory
+ of your WAR. The format of this config file is describe in the general adapter configuration
+ section.
+
+
+ Finally you must set the auth-method to KEYCLOAK in web.xml. You also
+ have to use standard servlet security to specify role-base constraints on your URLs. Here's an example
+ pulled from one of the examples that comes distributed with Keycloak.
+
+
+
+
+
+ customer-portal
+
+
+
+ Admins
+ /admin/*
+
+
+ admin
+
+
+
+
+ Customers
+ /customers/*
+
+
+ user
+
+
+
+
+
+ /*
+
+
+ CONFIDENTIAL
+
+
+
+
+ KEYCLOAK
+ this is ignored currently/realm-name>
+
+
+
+ admin
+
+
+ user
+
+
+]]>
+
+
+ ]
+
+
\ No newline at end of file
diff --git a/examples/wildfly-demo/README.md b/examples/wildfly-demo/README.md
index 6ebc17a542..9425964c6d 100755
--- a/examples/wildfly-demo/README.md
+++ b/examples/wildfly-demo/README.md
@@ -28,7 +28,7 @@ If you want to install Keycloak Server and run the demo on an existing Wildfly i
Obtain latest keycloak-war-dist-all.zip. This distro is used to install keycloak onto an existing JBoss installation
- $ cd ${jboss.home}/standalone
+ $ cd ${wildfly.home}/standalone
$ cp -r ${keycloak-war-dist-all}/deployments .
To install the adapter:
@@ -40,7 +40,13 @@ Step 2: Boot Keycloak Server
---------------------------------------
Where you go to start up the Keycloak Server depends on which distro you installed.
- $ ./bin/standalone.sh
+From appliance:
+$ cd keycloak/bin
+$ ./standalone.sh
+
+From existing Wildfly distro
+$ cd ${wildfly.home}
+$ ./standalone.sh
Step 3: Import the Test Realm
---------------------------------------