Chapter 2. Using OpenID Connect to secure applications and services

Procedure

1. Create a keycloak.json adapter configuration file within the WEB-INF directory of your WAR.

   The format of this configuration file is described in the Java adapter configuration section.

2. Set the auth-method to KEYCLOAK in web.xml.

3. Use standard servlet security to specify role-base constraints on your URLs.

   Here’s an example:

   <web-app xmlns="http://java.sun.com/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
         version="3.0">
   
       <module-name>application</module-name>
   
       <security-constraint>
           <web-resource-collection>
               <web-resource-name>Admins</web-resource-name>
               <url-pattern>/admin/*</url-pattern>
           </web-resource-collection>
           <auth-constraint>
               <role-name>admin</role-name>
           </auth-constraint>
           <user-data-constraint>
               <transport-guarantee>CONFIDENTIAL</transport-guarantee>
           </user-data-constraint>
       </security-constraint>
       <security-constraint>
           <web-resource-collection>
               <web-resource-name>Customers</web-resource-name>
               <url-pattern>/customers/*</url-pattern>
           </web-resource-collection>
           <auth-constraint>
               <role-name>user</role-name>
           </auth-constraint>
           <user-data-constraint>
               <transport-guarantee>CONFIDENTIAL</transport-guarantee>
           </user-data-constraint>
       </security-constraint>
   
       <login-config>
           <auth-method>KEYCLOAK</auth-method>
           <realm-name>this is ignored currently</realm-name>
       </login-config>
   
       <security-role>
           <role-name>admin</role-name>
       </security-role>
       <security-role>
           <role-name>user</role-name>
       </security-role>
   </web-app>

   Copy to Clipboard Toggle word wrap

Procedure

1. In the /WEB-INF/web.xml file, declare the necessary:

   • security constraints in the <security-constraint> element
   • login configuration in the <login-config> element

   • security roles in the <security-role> element.

     For example:

     <?xml version="1.0" encoding="UTF-8"?>
     <web-app xmlns="http://java.sun.com/xml/ns/javaee"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
              version="3.0">
     
         <module-name>customer-portal</module-name>
     
         <welcome-file-list>
             <welcome-file>index.html</welcome-file>
         </welcome-file-list>
     
         <security-constraint>
             <web-resource-collection>
                 <web-resource-name>Customers</web-resource-name>
                 <url-pattern>/customers/*</url-pattern>
             </web-resource-collection>
             <auth-constraint>
                 <role-name>user</role-name>
             </auth-constraint>
         </security-constraint>
     
         <login-config>
             <auth-method>BASIC</auth-method>
             <realm-name>does-not-matter</realm-name>
         </login-config>
     
         <security-role>
             <role-name>admin</role-name>
         </security-role>
         <security-role>
             <role-name>user</role-name>
         </security-role>
     </web-app>

     Copy to Clipboard Toggle word wrap

2. Add the jetty-web.xml file with the authenticator to the /WEB-INF/jetty-web.xml file.

   For example:

   <?xml version="1.0"?>
   <!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN"
    "http://www.eclipse.org/jetty/configure_9_0.dtd">
   <Configure class="org.eclipse.jetty.webapp.WebAppContext">
       <Get name="securityHandler">
           <Set name="authenticator">
               <New class="org.keycloak.adapters.jetty.KeycloakJettyAuthenticator">
               </New>
           </Set>
       </Get>
   </Configure>

   Copy to Clipboard Toggle word wrap
3. Within the /WEB-INF/ directory of your WAR, create a new file, keycloak.json. The format of this configuration file is described in the Java Adapters Config section. It is also possible to make this file available externally as described in Configuring the External Adapter.

4. Ensure your WAR application imports org.keycloak.adapters.jetty and maybe some more packages in the META-INF/MANIFEST.MF file, under the Import-Package header. Using maven-bundle-plugin in your project properly generates OSGI headers in manifest. Note that "*" resolution for the package does not import the org.keycloak.adapters.jetty package, since it is not used by the application or the Blueprint or Spring descriptor, but is rather used in the jetty-web.xml file.

   The list of the packages to import might look like this:

   org.keycloak.adapters.jetty;version="18.0.19.redhat-00001",
   org.keycloak.adapters;version="18.0.19.redhat-00001",
   org.keycloak.constants;version="18.0.19.redhat-00001",
   org.keycloak.util;version="18.0.19.redhat-00001",
   org.keycloak.*;version="18.0.19.redhat-00001",
   *;resolution:=optional

   Copy to Clipboard Toggle word wrap

Procedure

1. Red Hat Single Sign-On provides org.keycloak.adapters.osgi.undertow.PaxWebIntegrationService, which allows injecting jetty-web.xml and configuring security constraints for your application. You need to declare such services in the OSGI-INF/blueprint/blueprint.xml file inside your application. Note that your servlet needs to depend on it. An example configuration:

   <?xml version="1.0" encoding="UTF-8"?>
   <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
              http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
   
       <!-- Using jetty bean just for the compatibility with other fuse services -->
       <bean id="servletConstraintMapping" class="org.eclipse.jetty.security.ConstraintMapping">
           <property name="constraint">
               <bean class="org.eclipse.jetty.util.security.Constraint">
                   <property name="name" value="cst1"/>
                   <property name="roles">
                       <list>
                           <value>user</value>
                       </list>
                   </property>
                   <property name="authenticate" value="true"/>
                   <property name="dataConstraint" value="0"/>
               </bean>
           </property>
           <property name="pathSpec" value="/product-portal/*"/>
       </bean>
   
       <bean id="keycloakPaxWebIntegration" class="org.keycloak.adapters.osgi.PaxWebIntegrationService"
             init-method="start" destroy-method="stop">
           <property name="jettyWebXmlLocation" value="/WEB-INF/jetty-web.xml" />
           <property name="bundleContext" ref="blueprintBundleContext" />
           <property name="constraintMappings">
               <list>
                   <ref component-id="servletConstraintMapping" />
               </list>
           </property>
       </bean>
   
       <bean id="productServlet" class="org.keycloak.example.ProductPortalServlet" depends-on="keycloakPaxWebIntegration">
       </bean>
   
       <service ref="productServlet" interface="javax.servlet.Servlet">
           <service-properties>
               <entry key="alias" value="/product-portal" />
               <entry key="servlet-name" value="ProductServlet" />
               <entry key="keycloak.config.file" value="/keycloak.json" />
           </service-properties>
       </service>
   
   </blueprint>

   Copy to Clipboard Toggle word wrap
   • You might need to have the WEB-INF directory inside your project (even if your project is not a web application) and create the /WEB-INF/jetty-web.xml and /WEB-INF/keycloak.json files as in the Classic WAR application section. Note you don’t need the web.xml file as the security-constraints are declared in the blueprint configuration file.

2. The Import-Package in META-INF/MANIFEST.MF must contain at least these imports:

   org.keycloak.adapters.jetty;version="18.0.19.redhat-00001",
   org.keycloak.adapters;version="18.0.19.redhat-00001",
   org.keycloak.constants;version="18.0.19.redhat-00001",
   org.keycloak.util;version="18.0.19.redhat-00001",
   org.keycloak.*;version="18.0.19.redhat-00001",
   *;resolution:=optional

   Copy to Clipboard Toggle word wrap

1. Add META-INF/spring/beans.xml to your application, and in it, declare httpj:engine-factory with Jetty SecurityHandler with injected KeycloakJettyAuthenticator. The configuration for a CFX JAX-WS application might resemble this one:

   <?xml version="1.0" encoding="UTF-8"?>
   
   <beans xmlns="http://www.springframework.org/schema/beans"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xmlns:jaxws="http://cxf.apache.org/jaxws"
          xmlns:httpj="http://cxf.apache.org/transports/http-jetty/configuration"
          xsi:schemaLocation="
           http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
           http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd
           http://www.springframework.org/schema/osgi http://www.springframework.org/schema/osgi/spring-osgi.xsd
           http://cxf.apache.org/transports/http-jetty/configuration http://cxf.apache.org/schemas/configuration/http-jetty.xsd">
   
       <import resource="classpath:META-INF/cxf/cxf.xml" />
   
       <bean id="kcAdapterConfig" class="org.keycloak.representations.adapters.config.AdapterConfig">
           <property name="realm" value="demo"/>
           <property name="resource" value="custom-cxf-endpoint"/>
           <property name="bearerOnly" value="true"/>
           <property name="authServerUrl" value="http://localhost:8080/auth" />
           <property name="sslRequired" value="EXTERNAL"/>
       </bean>
   
       <bean id="keycloakAuthenticator" class="org.keycloak.adapters.jetty.KeycloakJettyAuthenticator">
           <property name="adapterConfig">
               <ref local="kcAdapterConfig" />
           </property>
       </bean>
   
       <bean id="constraint" class="org.eclipse.jetty.util.security.Constraint">
           <property name="name" value="Customers"/>
           <property name="roles">
               <list>
                   <value>user</value>
               </list>
           </property>
           <property name="authenticate" value="true"/>
           <property name="dataConstraint" value="0"/>
       </bean>
   
       <bean id="constraintMapping" class="org.eclipse.jetty.security.ConstraintMapping">
           <property name="constraint" ref="constraint"/>
           <property name="pathSpec" value="/*"/>
       </bean>
   
       <bean id="securityHandler" class="org.eclipse.jetty.security.ConstraintSecurityHandler">
           <property name="authenticator" ref="keycloakAuthenticator" />
           <property name="constraintMappings">
               <list>
                   <ref local="constraintMapping" />
               </list>
           </property>
           <property name="authMethod" value="BASIC"/>
           <property name="realmName" value="does-not-matter"/>
       </bean>
   
       <httpj:engine-factory bus="cxf" id="kc-cxf-endpoint">
           <httpj:engine port="8282">
               <httpj:handlers>
                   <ref local="securityHandler" />
               </httpj:handlers>
               <httpj:sessionSupport>true</httpj:sessionSupport>
           </httpj:engine>
       </httpj:engine-factory>
   
       <jaxws:endpoint
                       implementor="org.keycloak.example.ws.ProductImpl"
                       address="http://localhost:8282/ProductServiceCF" depends-on="kc-cxf-endpoint" />
   
   </beans>

   Copy to Clipboard Toggle word wrap

   For the CXF JAX-RS application, the only difference might be in the configuration of the endpoint dependent on engine-factory:

   <jaxrs:server serviceClass="org.keycloak.example.rs.CustomerService" address="http://localhost:8282/rest"
       depends-on="kc-cxf-endpoint">
       <jaxrs:providers>
           <bean class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
       </jaxrs:providers>
   </jaxrs:server>

   Copy to Clipboard Toggle word wrap
2. The Import-Package in META-INF/MANIFEST.MF must contain those imports:

Procedure

1. Add these properties to the $FUSE_HOME/etc/system.properties file:

   hawtio.keycloakEnabled=true
   hawtio.realm=keycloak
   hawtio.keycloakClientConfig=file://${karaf.base}/etc/keycloak-hawtio-client.json
   hawtio.rolePrincipalClasses=org.keycloak.adapters.jaas.RolePrincipal,org.apache.karaf.jaas.boot.principal.RolePrincipal

   Copy to Clipboard Toggle word wrap
2. Create a client in the Red Hat Single Sign-On Admin Console in your realm. For example, in the Red Hat Single Sign-On demo realm, create a client hawtio-client, specify public as the Access Type, and specify a redirect URI pointing to Hawtio: http://localhost:8181/hawtio/*. You must also have a corresponding Web Origin configured (in this case, http://localhost:8181).
3. Create the keycloak-hawtio-client.json file in the $FUSE_HOME/etc directory using content similar to that shown in the example below. Change the realm, resource, and auth-server-url properties according to your Red Hat Single Sign-On environment. The resource property must point to the client created in the previous step. This file is used by the client (Hawtio JavaScript application) side.

1. Create the keycloak-hawtio.json file in the $FUSE_HOME/etc dicrectory using content similar to that shown in the example below. Change the realm and auth-server-url properties according to your Red Hat Single Sign-On environment. This file is used by the adapters on the server (JAAS Login module) side.

   {
     "realm" : "demo",
     "resource" : "jaas",
     "bearer-only" : true,
     "auth-server-url" : "http://localhost:8080/auth",
     "ssl-required" : "external",
     "use-resource-role-mappings": false,
     "principal-attribute": "preferred_username"
   }

   Copy to Clipboard Toggle word wrap

2. Start JBoss Fuse 6.3.0 Rollup 12 and install the keycloak feature if you have not already done so. The commands in Karaf terminal are similar to this example:

   features:addurl mvn:org.keycloak/keycloak-osgi-features/18.0.19.redhat-00001/xml/features
   features:install keycloak

   Copy to Clipboard Toggle word wrap

3. Go to http://localhost:8181/hawtio and log in as a user from your Red Hat Single Sign-On realm.

   Note that the user needs to have the proper realm role to successfully authenticate to Hawtio. The available roles are configured in the $FUSE_HOME/etc/system.properties file in hawtio.roles.

Procedure

1. In the /WEB-INF/web.xml file, declare the necessary:

   • security constraints in the <security-constraint> element
   • login configuration in the <login-config> element. Make sure that the <auth-method> is KEYCLOAK.

   • security roles in the <security-role> element

     For example:

     <?xml version="1.0" encoding="UTF-8"?>
     <web-app xmlns="http://java.sun.com/xml/ns/javaee"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
              version="3.0">
     
         <module-name>customer-portal</module-name>
     
         <welcome-file-list>
             <welcome-file>index.html</welcome-file>
         </welcome-file-list>
     
         <security-constraint>
             <web-resource-collection>
                 <web-resource-name>Customers</web-resource-name>
                 <url-pattern>/customers/*</url-pattern>
             </web-resource-collection>
             <auth-constraint>
                 <role-name>user</role-name>
             </auth-constraint>
         </security-constraint>
     
         <login-config>
             <auth-method>KEYCLOAK</auth-method>
             <realm-name>does-not-matter</realm-name>
         </login-config>
     
         <security-role>
             <role-name>admin</role-name>
         </security-role>
         <security-role>
             <role-name>user</role-name>
         </security-role>
     </web-app>

     Copy to Clipboard Toggle word wrap

2. Within the /WEB-INF/ directory of your WAR, create a new file, keycloak.json. The format of this configuration file is described in the Java Adapters Config section. It is also possible to make this file available externally as described in Configuring the External Adapter.

   For example:

   {
       "realm": "demo",
       "resource": "customer-portal",
       "auth-server-url": "http://localhost:8080/auth",
       "ssl-required" : "external",
       "credentials": {
           "secret": "password"
       }
   }

   Copy to Clipboard Toggle word wrap
3. Contrary to the Fuse 6 adapter, there are no special OSGi imports needed in MANIFEST.MF.

Procedure

1. Red Hat Single Sign-On provides org.keycloak.adapters.osgi.undertow.PaxWebIntegrationService, which allows configuring authentication method and security constraints for your application. You need to declare such services in the OSGI-INF/blueprint/blueprint.xml file inside your application. Note that your servlet needs to depend on it. An example configuration:

   <?xml version="1.0" encoding="UTF-8"?>
   <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
   
       <bean id="servletConstraintMapping" class="org.keycloak.adapters.osgi.PaxWebSecurityConstraintMapping">
           <property name="roles">
               <list>
                   <value>user</value>
               </list>
           </property>
           <property name="authentication" value="true"/>
           <property name="url" value="/product-portal/*"/>
       </bean>
   
       <!-- This handles the integration and setting the login-config and security-constraints parameters -->
       <bean id="keycloakPaxWebIntegration" class="org.keycloak.adapters.osgi.undertow.PaxWebIntegrationService"
             init-method="start" destroy-method="stop">
           <property name="bundleContext" ref="blueprintBundleContext" />
           <property name="constraintMappings">
               <list>
                   <ref component-id="servletConstraintMapping" />
               </list>
           </property>
       </bean>
   
       <bean id="productServlet" class="org.keycloak.example.ProductPortalServlet" depends-on="keycloakPaxWebIntegration" />
   
       <service ref="productServlet" interface="javax.servlet.Servlet">
           <service-properties>
               <entry key="alias" value="/product-portal" />
               <entry key="servlet-name" value="ProductServlet" />
               <entry key="keycloak.config.file" value="/keycloak.json" />
           </service-properties>
       </service>
   </blueprint>

   Copy to Clipboard Toggle word wrap

   You might need to have the WEB-INF directory inside your project (even if your project is not a web application) and create the /WEB-INF/keycloak.json file as described in the Classic WAR application section. Note you don’t need the web.xml file as the security-constraints are declared in the blueprint configuration file.

2. Contrary to the Fuse 6 adapter, there are no special OSGi imports needed in MANIFEST.MF.

Procedure

1. Add OSGI-INF/blueprint/blueprint.xml to your application, and in it, add the proper configuration resolver bean similarly to Camel configuration. In the httpu:engine-factory declare org.keycloak.adapters.osgi.undertow.CxfKeycloakAuthHandler handler using that camel configuration. The configuration for a CFX JAX-WS application might resemble this one:

   <?xml version="1.0" encoding="UTF-8"?>
   <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xmlns:jaxws="http://cxf.apache.org/blueprint/jaxws"
              xmlns:cxf="http://cxf.apache.org/blueprint/core"
              xmlns:httpu="http://cxf.apache.org/transports/http-undertow/configuration".
              xsi:schemaLocation="
         http://cxf.apache.org/transports/http-undertow/configuration http://cxf.apache.org/schemas/configuration/http-undertow.xsd
         http://cxf.apache.org/blueprint/core http://cxf.apache.org/schemas/blueprint/core.xsd
         http://cxf.apache.org/blueprint/jaxws http://cxf.apache.org/schemas/blueprint/jaxws.xsd">
   
       <bean id="keycloakConfigResolver" class="org.keycloak.adapters.osgi.BundleBasedKeycloakConfigResolver" >
           <property name="bundleContext" ref="blueprintBundleContext" />
       </bean>
   
       <httpu:engine-factory bus="cxf" id="kc-cxf-endpoint">
           <httpu:engine port="8282">
               <httpu:handlers>
                   <bean class="org.keycloak.adapters.osgi.undertow.CxfKeycloakAuthHandler">
                       <property name="configResolver" ref="keycloakConfigResolver" />
                   </bean>
               </httpu:handlers>
           </httpu:engine>
       </httpu:engine-factory>
   
       <jaxws:endpoint implementor="org.keycloak.example.ws.ProductImpl"
                       address="http://localhost:8282/ProductServiceCF" depends-on="kc-cxf-endpoint"/>
   
   </blueprint>

   Copy to Clipboard Toggle word wrap

   For the CXF JAX-RS application, the only difference might be in the configuration of the endpoint dependent on engine-factory:

   <jaxrs:server serviceClass="org.keycloak.example.rs.CustomerService" address="http://localhost:8282/rest"
       depends-on="kc-cxf-endpoint">
       <jaxrs:providers>
           <bean class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
       </jaxrs:providers>
   </jaxrs:server>

   Copy to Clipboard Toggle word wrap
2. The Import-Package in META-INF/MANIFEST.MF must contain those imports:

Procedure

1. Create a client in the Red Hat Single Sign-On Admin Console in your realm. For example, in the Red Hat Single Sign-On demo realm, create a client hawtio-client, specify public as the Access Type, and specify a redirect URI pointing to Hawtio: http://localhost:8181/hawtio/*. Configure corresponding Web Origin (in this case, http://localhost:8181). Setup client scope mapping to include view-profile client role of account client in Scope tab in hawtio-client client detail.

2. Create the keycloak-hawtio-client.json file in the $FUSE_HOME/etc directory using content similar to that shown in the example below. Change the realm, resource, and auth-server-url properties according to your Red Hat Single Sign-On environment. The resource property must point to the client created in the previous step. This file is used by the client (Hawtio JavaScript application) side.

   {
     "realm" : "demo",
     "clientId" : "hawtio-client",
     "url" : "http://localhost:8080/auth",
     "ssl-required" : "external",
     "public-client" : true
   }

   Copy to Clipboard Toggle word wrap

3. Create the keycloak-direct-access.json file in the $FUSE_HOME/etc directory using content similar to that shown in the example below. Change the realm and url properties according to your Red Hat Single Sign-On environment. This file is used by JavaScript client.

   {
     "realm" : "demo",
     "resource" : "ssh-jmx-admin-client",
     "auth-server-url" : "http://localhost:8080/auth",
     "ssl-required" : "external",
     "credentials": {
       "secret": "password"
     }
   }

   Copy to Clipboard Toggle word wrap

4. Create the keycloak-hawtio.json file in the $FUSE_HOME/etc dicrectory using content similar to that shown in the example below. Change the realm and auth-server-url properties according to your Red Hat Single Sign-On environment. This file is used by the adapters on the server (JAAS Login module) side.

   {
     "realm" : "demo",
     "resource" : "jaas",
     "bearer-only" : true,
     "auth-server-url" : "http://localhost:8080/auth",
     "ssl-required" : "external",
     "use-resource-role-mappings": false,
     "principal-attribute": "preferred_username"
   }

   Copy to Clipboard Toggle word wrap

5. Start JBoss Fuse 7.4.0, install the Keycloak feature. Then type in the Karaf terminal:

   system:property -p hawtio.keycloakEnabled true
   system:property -p hawtio.realm keycloak
   system:property -p hawtio.keycloakClientConfig file://\${karaf.base}/etc/keycloak-hawtio-client.json
   system:property -p hawtio.rolePrincipalClasses org.keycloak.adapters.jaas.RolePrincipal,org.apache.karaf.jaas.boot.principal.RolePrincipal
   restart io.hawt.hawtio-war

   Copy to Clipboard Toggle word wrap

6. Go to http://localhost:8181/hawtio and log in as a user from your Red Hat Single Sign-On realm.

   Note that the user needs to have the proper realm role to successfully authenticate to Hawtio. The available roles are configured in the $FUSE_HOME/etc/system.properties file in hawtio.roles.

Procedure

1. To add the starter to your project using Maven, add the following to your dependencies:

   <dependency>
       <groupId>org.keycloak</groupId>
       <artifactId>keycloak-spring-boot-starter</artifactId>
   </dependency>

   Copy to Clipboard Toggle word wrap

2. Add the Adapter BOM dependency:

   <dependencyManagement>
     <dependencies>
       <dependency>
         <groupId>org.keycloak.bom</groupId>
         <artifactId>keycloak-adapter-bom</artifactId>
         <version>18.0.19.redhat-00001</version>
         <type>pom</type>
         <scope>import</scope>
       </dependency>
     </dependencies>
   </dependencyManagement>

   Copy to Clipboard Toggle word wrap

Procedure

1. Instead of a keycloak.json file, you configure the realm for the Spring Boot adapter via the normal Spring Boot configuration. For example:

   keycloak.realm = demorealm
   keycloak.auth-server-url = http://127.0.0.1:8080/auth
   keycloak.ssl-required = external
   keycloak.resource = demoapp
   keycloak.credentials.secret = 11111111-1111-1111-1111-111111111111
   keycloak.use-resource-role-mappings = true

   Copy to Clipboard Toggle word wrap

   You can disable the Keycloak Spring Boot Adapter (for example in tests) by setting keycloak.enabled = false.

2. To configure a Policy Enforcer, unlike keycloak.json, use policy-enforcer-config instead of just policy-enforcer.

3. Specify the Jakarta EE security config that would normally go in the web.xml.

   The Spring Boot Adapter will set the login-method to KEYCLOAK and configure the security-constraints at startup time. Here’s an example configuration:

   keycloak.securityConstraints[0].authRoles[0] = admin
   keycloak.securityConstraints[0].authRoles[1] = user
   keycloak.securityConstraints[0].securityCollections[0].name = insecure stuff
   keycloak.securityConstraints[0].securityCollections[0].patterns[0] = /insecure
   
   keycloak.securityConstraints[1].authRoles[0] = admin
   keycloak.securityConstraints[1].securityCollections[0].name = admin stuff
   keycloak.securityConstraints[1].securityCollections[0].patterns[0] = /admin

   Copy to Clipboard Toggle word wrap

1. User sends logout request from one application
2. The application sends logout request to Red Hat Single Sign-On
3. The Red Hat Single Sign-On server invalidates the user session
4. The Red Hat Single Sign-On server then sends a backchannel request to application with an admin url that are associated with the session
5. When an application receives the logout request it invalidates the corresponding HTTP session

1. When a new application node joins the cluster, it sends a registration request to the Red Hat Single Sign-On server
2. The request may be re-sent to Red Hat Single Sign-On in configured periodic intervals
3. If the Red Hat Single Sign-On server doesn’t receive a re-registration request within a specified timeout then it automatically unregisters the specific node
4. The node is also unregistered in Red Hat Single Sign-On when it sends an unregistration request, which is usually during node shutdown or application undeployment. This may not work properly for forced shutdown when undeployment listeners are not invoked, which results in the need for automatic unregistration