JBoss/Wildfly Adapter
To be able to secure WAR apps deployed on JBoss AS 7.1.1, JBoss EAP 6.x, or Wildfly, you must install and
configure the Keycloak Subsystem. You then have two options to secure your WARs. You can provide a keycloak
config file in your WAR and change the auth-method to KEYCLOAK within web.xml. Alternatively, you don't have
to crack open your WARs at all and can apply Keycloak via the Keycloak Subsystem configuration in standalone.xml.
Both methods are described in this section.
Adapter Installation
Adapters are no longer included with the appliance or war distribution. Each adapter is a separate download on
the Keycloak download site. They are also available as a maven artifact.
Install on Wildfly 9 or 10:
$ cd $WILDFLY_HOME
$ unzip keycloak-wildfly-adapter-dist.zip
Install on Wildfly 8:
$ cd $WILDFLY_HOME
$ unzip keycloak-wf8-adapter-dist.zip
Install on JBoss EAP 6.x:
$ cd $JBOSS_HOME
$ unzip keycloak-eap6-adapter-dist.zip
Install on JBoss AS 7.1.1:
$ cd $JBOSS_HOME
$ unzip keycloak-as7-adapter-dist.zip
This zip file creates new JBoss Modules specific to the Wildfly Keycloak Adapter within your Wildfly distro.
After adding the Keycloak modules, you must then enable the Keycloak Subsystem within your app server's server configuration:
domain.xml or standalone.xml.
There is a CLI script that will help you modify your server configuration. Start the server and run the script
from the server's bin directory:
$ cd $JBOSS_HOME/bin
$ jboss-cli.sh -c --file=adapter-install.cli
The script will add the extension, subsystem, and optional security-domain as described below.
For more recent versions of WildFly there's also a offline CLI script that can be used to install the adapter while the server is not running:
$ cd $JBOSS_HOME/bin
$ jboss-cli.sh -c --file=adapter-install-offline.cli
...
...
]]>
The keycloak security domain should be used with EJBs and other components when you need the security context created
in the secured web tier to be propagated to the EJBs (other EE component) you are invoking. Otherwise
this configuration is optional.
...
]]>
For example, if you have a JAX-RS service that is an EJB within your WEB-INF/classes directory, you'll want
to annotate it with the @SecurityDomain annotation as follows:
getCustomers() {
return db.getCustomers();
}
}
]]>
We hope to improve our integration in the future so that you don't have to specify the @SecurityDomain
annotation when you want to propagate a keycloak security context to the EJB tier.
Required Per WAR Configuration
This section describes how to secure a WAR directly by adding config and editing files within your WAR package.
The first thing you must do is 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.
Next 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-portalAdmins/admin/*adminCONFIDENTIALCustomers/customers/*userCONFIDENTIALKEYCLOAKthis is ignored currentlyadminuser
]]>
Securing WARs via Keycloak Subsystem
You do not have to crack open a WAR to secure it with Keycloak. Alternatively, you can externally secure
it via the Keycloak Adapter Subsystem. While you don't have to specify KEYCLOAK as an auth-method,
you still have to define the security-constraints in web.xml. You do
not, however, have to create a WEB-INF/keycloak.json file. This metadata is instead defined
within XML in your server's domain.xml or standalone.xml subsystem
configuration section.
demoMIGfMA0GCSqGSIb3DQEBAQUAAhttp://localhost:8081/authexternalcustomer-portalpassword
]]>
The secure-deploymentname attribute identifies the WAR you want
to secure. Its value is the module-name defined in web.xml with
.war appended. The rest of the configuration corresponds pretty much one to one
with the keycloak.json configuration options defined in general adapter configuration.
The exception is the credential element.
To make it easier for you, you can go to the Keycloak Adminstration Console and go to the Application/Installation
tab of the application this WAR is aligned with. It provides an example XML file you can cut and paste.
There is an additional convenience format for this XML if you have multiple WARs you are deployment that
are secured by the same domain. This format allows you to define common configuration items in one place
under the realm element.
MIGfMA0GCSqGSIb3DQEBAhttp://localhost:8080/authexternaldemocustomer-portalpassworddemoproduct-portalpassworddemodatabase-servicetrue
]]>