sync with latest changes

topics/oidc/java/fuse-adapter.adoc

@@ -22,51 +22,7 @@ What is supported for Fuse is:
 Basically all mentioned web applications require to inject {{book.project.name}} Jetty authenticator into underlying Jetty server . The steps to achieve it are bit different
 according to application type. The details are described in individual sub-chapters.
 
-<<<<<<< HEAD
-===== Builtin CXF web applications
-
-Some services automatically come with deployed servlets on startup. One of such examples is CXF servlet running on
-http://localhost:8181/cxf context. Securing such endpoints is quite tricky. The approach, which Keycloak is currently using,
-is providing ServletReregistrationService, which undeploys builtin servlet at startup, so you are able to re-deploy it again on context secured by Keycloak.
-You can see the `OSGI-INF/blueprint/blueprint.xml` inside `cxf-jaxrs` example, which adds JAX-RS `customerservice` endpoint and more importantly, it secures whole `/cxf` context.
-
-As a side effect, all other CXF services running on default CXF HTTP destination will be secured too. Once you uninstall feature `keycloak-fuse-6.2-example`, the
-original unsecured servlet on `/cxf` context is deployed back and hence context will become unsecured again.
-
-It's recommended to use your own Jetty engine for your apps (similarly like `cxf-jaxws` application is doing).
-
-
-==== How to secure Fuse admin services
-
-===== SSH authentication to Fuse terminal with Keycloak credentials
-
-Keycloak mainly addresses usecases for authentication of web applications, however if your admin services (like fuse admin console) are protected
-with Keycloak, it may be good to protect non-web services like SSH with Keycloak credentials too. It's possible to do it by using JAAS login module, which
-allows to remotely connect to Keycloak and verify credentials based on 
-
-// <<_direct_access_grants,Direct Access Grants>> .
-
-Example steps for enable SSH authentication require changing the configuration of `sshRealm` in `$FUSE_HOME/etc/org.apache.karaf.shell.cfg`, then adding
-file `$FUSE_HOME/etc/keycloak-direct-access.json` (this is default location, which can be changed) and install the needed feature `keycloak-jaas`. It's described in details
-in the README file of Fuse example, which in example distribution is inside `fuse/fuse-admin/README.md` .
-
-
-===== JMX authentication with Keycloak credentials
-
-This may be needed in case if you really want to use jconsole or other external tool to perform remote connection to JMX through RMI. Otherwise it may
-be better to use just hawt.io/jolokia as jolokia agent is installed in http://hawt.io by default.
-
-You need to configure `jmxRealm` in `$FUSE_HOME/etc/org.apache.karaf.management.cfg`, then adding file `$FUSE_HOME/etc/keycloak-direct-access.json`
-(this is default location, which can be changed) and install the needed feature `keycloak-jaas`.
-It's described in details in the README file of Fuse example, which in example distribution is inside `fuse/fuse-admin/README.md` .
-
-
-===== Secure Fuse admin console
-
-Fuse admin console is Hawt.io. See http://hawt.io/configuration/index.html[Hawt.io documentation] for more info about how to secure it with Keycloak.
-=======
 {% if book.community %}
 The best place to start is look at Fuse demo bundled as part of {{book.project.name}} examples in directory `fuse` . Most of the steps should be understandable from testing and
 understanding the demo.
 {% endif %}
->>>>>>> 163974a212546af0df02970a57466a056b83ba5a

topics/oidc/java/jboss-adapter.adoc

@@ -174,10 +174,8 @@ public class CustomerService {
 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 <<fake/../java-adapter-config.adoc#_java_adapter_config,Java 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.
 
@@ -261,9 +259,7 @@ This metadata is instead defined within server configuration (i.e. `standalone.x
 
 The `secure-deployment` `name` 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 <<fake/../java-adapter-config.adoc#_java_adapter_config,Java adapter configuration>>.
-
 The exception is the `credential` element. 
 
 To make it easier for you, you can go to the {{book.project.title}} Administration Console and go to the Application/Installation tab of the application this WAR is aligned with.

topics/oidc/java/jetty9-adapter.adoc

@@ -1,3 +1,4 @@
+
 [[_jetty9_adapter]]
 === Jetty 9.x Adapters
 
@@ -5,7 +6,7 @@ Keycloak has a separate adapter for Jetty 9.1.x and Jetty 9.2.x that you will ha
 You then have to provide some extra configuration in each WAR you deploy to Jetty.
 Let's go over these steps. 
 
-[[_jetty-9_adapter_installation]]
+[[_jetty9_adapter_installation]]
 ==== Adapter Installation
 
 Adapters are no longer included with the appliance or war distribution.Each adapter is a separate download on the Keycloak download site.
@@ -57,10 +58,8 @@ This is a Jetty specific config file and you must define a Keycloak specific aut
 ----
 
 Next 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 <<fake/../java-adapter-config.adoc#_java_adapter_config,Java adapter configuration>>            section.
 
-
 WARNING: The Jetty 9.1.x adapter will not be able to find the `keycloak.json` file.
 You will have to define all adapter settings within the `jetty-web.xml` file as described below. 
 

topics/oidc/java/tomcat-adapter.adoc

@@ -45,10 +45,8 @@ This is a Tomcat specific config file and you must define a Keycloak specific Va
 ----
 
 Next 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 <<fake/../java-adapter-config.adoc#_java_adapter_config,Java adapter configuration>>            section.
 
-
 Finally you must specify both a `login-config` and use standard servlet security to specify role-base constraints on your URLs.
 Here's an example: 
 

topics/oidc/oidc-generic.adoc

@@ -118,6 +118,7 @@ browser history. This is somewhat mitigated by using short expiration for Access
 
 For more details refer to the http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth[Implicit Flow] in the OpenID Connect specification.
 
+[[_resource_owner_password_credentials_flow]]
 ==== Resource Owner Password Credentials
 
 Resource Owner Password Credentials, referred to as Direct Grant in {{book.project.name}}, allows exchanging user credentials for tokens. It's not recommended

topics/oidc/oidc-overview.adoc

@@ -2,5 +2,3 @@
 
 This section describes how you can secure applications and services with OpenID Connect using either {{book.project.name}} adapters or generic OpenID Connect
 Resource Provider libraries.
-
-// TODO: Update the cross-reference <<_direct_access_grants,Direct Access Grants>>  in the topic /oidc/java/fuse-adapter.adoc