diff --git a/securing_apps/topics/client-registration.adoc b/securing_apps/topics/client-registration.adoc
index 8d11cecaf7..7c45920c15 100644
--- a/securing_apps/topics/client-registration.adoc
+++ b/securing_apps/topics/client-registration.adoc
@@ -1,4 +1,4 @@
-[[_client_registration]]
+[[client_registration]]
 == Client Registration
 
 In order for an application or service to utilize {project_name} it has to register a client in {project_name}.
@@ -32,7 +32,7 @@ The bearer token can be issued on behalf of a user or a Service Account. The fol
 
 If you are using a bearer token to create clients it's recommend to use a token from a Service Account with only the `create-client` role (see link:{adminguide_link}[{adminguide_name}] for more details).
 
-[[_initial_access_token]]
+[[initial_access_token]]
 ==== Initial Access Token
 
 The recommended approach to registering new clients is by using initial access tokens.
@@ -55,7 +55,7 @@ For example:
 ----
 Authorization: bearer eyJhbGciOiJSUz...
 ----            
-[[_registration_access_token]]
+[[registration_access_token]]
 ==== Registration Access Token
 
 When you create a client through the Client Registration Service the response will include a registration access token.
diff --git a/securing_apps/topics/client-registration/client-registration-cli.adoc b/securing_apps/topics/client-registration/client-registration-cli.adoc
index 210dc94d03..9bf271a17b 100644
--- a/securing_apps/topics/client-registration/client-registration-cli.adoc
+++ b/securing_apps/topics/client-registration/client-registration-cli.adoc
@@ -1,4 +1,4 @@
-[[_client_registration_cli]]
+[[client_registration_cli]]
 == Client Registration CLI
 
 The Client Registration CLI is a command-line interface (CLI) tool for application developers to configure new clients in a self-service manner when integrating with {project_name}. It is specifically designed to interact with {project_name} Client Registration REST endpoints.
@@ -10,7 +10,7 @@ You can configure application clients from a command line with the Client Regist
 To allow a particular user to use `Client Registration CLI` the {project_name} administrator typically uses the Admin Console to configure a new user with proper roles or to configure a new client and client secret to grant access to the Client Registration REST API.
 
 
-[[_configuring_a_user_for_client_registration_cli]]
+[[configuring_a_user_for_client_registration_cli]]
 === Configuring a new regular user for use with Client Registration CLI
 
 . Log in to the Admin Console (for example, http://localhost:8080/auth/admin) as [command]`admin`.
@@ -29,7 +29,7 @@ It is possible to not assign any [command]`realm-management` roles to a user. In
 The Administrator can issue Initial Access Tokens from the Admin Console through the *Realm Settings > Client Registration > Initial Access Token* menu.
 
 
-[[_configuring_a_client_for_use_with_client_registration_cli]]
+[[configuring_a_client_for_use_with_client_registration_cli]]
 === Configuring a client for use with the Client Registration CLI
 
 By default, the server recognizes the Client Registration CLI as the [filename]`admin-cli` client, which is configured automatically for every new realm. No additional client configuration is necessary when logging in with a user name.
@@ -50,7 +50,7 @@ You can configure either [filename]`Client Id and Secret` or [filename]`Signed J
 . With the service account enabled, you can omit specifying the user when running [command]`kcreg config credentials` and only provide the client secret or keystore information.
 
 
-[[_installing_client_registration_cli]]
+[[installing_client_registration_cli]]
 === Installing the Client Registration CLI
 
 The Client Registration CLI is packaged inside the {project_name} Server distribution. You can find execution scripts inside the [filename]`bin` directory. The Linux script is called [filename]`kcreg.sh`, and the Windows script is called [filename]`kcreg.bat`.
@@ -75,7 +75,7 @@ c:\> kcreg
 [filename]`KEYCLOAK_HOME` refers to a directory where the {project_name} Server distribution was unpacked.
 
 
-[[_using_client_registration_cli]]
+[[using_client_registration_cli]]
 === Using the Client Registration CLI
 
 . Start an authenticated session by logging in with your credentials.
@@ -122,7 +122,7 @@ c:\> kcreg config truststore --trustpass %PASSWORD% %HOMEPATH%\.keycloak\trustst
 ----
 
 
-[[_logging_in]]
+[[logging_in]]
 ==== Logging in
 
 . Specify a server endpoint URL and a realm when you log in with the Client Registration CLI.
@@ -152,7 +152,7 @@ c:\> kcreg help
 See [filename]`kcreg config credentials --help` for more information about starting an authenticated session.
 
 
-[[_working_with_alternative_configurations]]
+[[working_with_alternative_configurations]]
 ==== Working with alternative configurations
 
 By default, the Client Registration CLI automatically maintains a configuration file at a default location, [filename]`./.keycloak/kcreg.config`, under the user's home directory. You can use the [command]`--config` option to point to a different file or location to mantain multiple authenticated sessions in parallel. It is the safest way to perform operations tied to a single configuration file from a single thread.
@@ -165,7 +165,7 @@ Do not make the configuration file visible to other users on the system. The con
 You might want to avoid storing secrets inside a configuration file by using the [command]`--no-config` option with all of your commands, even though it is less convenient and requires more token requests to do so. Specify all authentication information with each [command]`kcreg` invocation.
 
 
-[[_initial_access_and_registration_access_tokens]]
+[[initial_access_and_registration_access_tokens]]
 ==== Initial Access and Registration Access Tokens
 
 Developers who do not have an account configured at the {project_name} server they want to use can use the Client Registration CLI. This is possible only when the realm administrator issues a developer an Initial Access Token. It is up to the realm administrator to decide how and when to issue and distribute these tokens. The realm administrator can limit the maximum age of the Initial Access Token and the total number of clients that can be created with it.
@@ -211,7 +211,7 @@ See <<_client_registration, Client Registration>> for more information about Ini
 Run the [command]`kcreg config initial-token --help` and [command]`kcreg config registration-token --help` commands for more information on how to configure tokens with the Client Registration CLI.
 
 
-[[_performing_crud_operations]]
+[[performing_crud_operations]]
 ==== Creating a client configuration
 
 The first task after authenticating with credentials or configuring an Initial Access Token is usually to create a new client. Often you might want to use a prepared JSON file as a template and set or override some of the attributes.
@@ -344,7 +344,7 @@ C:\> kcreg delete myclient
 Run the [command]`kcreg delete --help` command for more information about the [command]`kcreg delete` command.
 
 
-[[_refreshing_invalid_registration_access_tokens]]
+[[refreshing_invalid_registration_access_tokens]]
 ==== Refreshing invalid Registration Access Tokens
 
 When performing a create, read, update, and delete (CRUD) operation using the [command]`--no-config` mode, the Client Registration CLI cannot handle Registration Access Tokens for you. In that case, it is possible to lose track of the most recently issued Registration Access Token for a client, which makes it impossible to perform any further CRUD operations on that client without authenticating with an account that has *manage-clients* permissions.
@@ -354,7 +354,7 @@ If you have permissions, you can issue a new Registration Access Token for the c
 Run the [command]`kcreg update-token --help` command for more information about the [command]`kcreg update-token` command.
 
 
-[[_troubleshooting_2]]
+[[troubleshooting_2]]
 === Troubleshooting
 
 * Q: When logging in, I get an error: *Parameter client_assertion_type is missing [invalid_client].
diff --git a/securing_apps/topics/oidc/java/adapter_error_handling.adoc b/securing_apps/topics/oidc/java/adapter_error_handling.adoc
index cb9a5c5966..7c479e9b50 100644
--- a/securing_apps/topics/oidc/java/adapter_error_handling.adoc
+++ b/securing_apps/topics/oidc/java/adapter_error_handling.adoc
@@ -1,5 +1,5 @@
 
-[[_adapter_error_handling]]
+[[adapter_error_handling]]
 ==== Error Handling
 
 {project_name} has some error handling facilities for servlet based client adapters.
diff --git a/securing_apps/topics/oidc/java/application-clustering.adoc b/securing_apps/topics/oidc/java/application-clustering.adoc
index b85fa5419f..8b2e0e9a1c 100644
--- a/securing_apps/topics/oidc/java/application-clustering.adoc
+++ b/securing_apps/topics/oidc/java/application-clustering.adoc
@@ -1,4 +1,4 @@
-[[_applicationclustering]]
+[[applicationclustering]]
 ==== Application Clustering
 
 ifeval::[{project_community}==true]
@@ -67,7 +67,7 @@ For example the way backchannel logout works is:
 
 If admin URL contains `${application.session.host}` it will be replaced with the URL to the node associated with the HTTP session.
 
-[[_registration_app_nodes]]
+[[registration_app_nodes]]
 ===== Registration of application nodes
 
 The previous section describes how {project_name} can send logout request to node associated with a specific HTTP session.
@@ -99,7 +99,7 @@ In the {project_name} Administration Console you can specify the maximum node re
 the adapter configuration). You can also manually add and remove cluster nodes in through the Adminstration Console, which is useful if you don't want to rely
 on the automatic registration feature or if you want to remove stale application nodes in the event your not using the automatic unregistration feature.
 
-[[_refresh_token_each_req]]
+[[refresh_token_each_req]]
 ===== Refresh token in each request
 
 By default the application adapter will only refresh the access token when it's expired. However, you can also configure the adapter to refresh the token on every
diff --git a/securing_apps/topics/oidc/java/client-authentication.adoc b/securing_apps/topics/oidc/java/client-authentication.adoc
index 9c09d594e4..8f292eabda 100644
--- a/securing_apps/topics/oidc/java/client-authentication.adoc
+++ b/securing_apps/topics/oidc/java/client-authentication.adoc
@@ -1,4 +1,4 @@
-[[_client_authentication_adapter]]
+[[client_authentication_adapter]]
 ==== Client Authentication
 
 When a confidential OIDC client needs to send a backchannel request (for example, to exchange code for the token, or to refresh the token) it needs to authenticate against the {project_name} server. By default, there are three ways to authenticate the client: client ID and client secret, client authentication with signed JWT, or client authentication with signed JWT using client secret.
diff --git a/securing_apps/topics/oidc/java/fuse-adapter.adoc b/securing_apps/topics/oidc/java/fuse-adapter.adoc
index 74f9c4dc42..2ad229b699 100644
--- a/securing_apps/topics/oidc/java/fuse-adapter.adoc
+++ b/securing_apps/topics/oidc/java/fuse-adapter.adoc
@@ -1,5 +1,5 @@
 
-[[_fuse_adapter]]
+[[fuse_adapter]]
 ==== JBoss Fuse 6 Adapter
 
 {project_name} supports securing your web applications running inside https://developers.redhat.com/products/fuse/overview/[JBoss Fuse 6].
diff --git a/securing_apps/topics/oidc/java/fuse/camel.adoc b/securing_apps/topics/oidc/java/fuse/camel.adoc
index af5b5041ed..420bfffc17 100644
--- a/securing_apps/topics/oidc/java/fuse/camel.adoc
+++ b/securing_apps/topics/oidc/java/fuse/camel.adoc
@@ -1,4 +1,4 @@
-[[_fuse_adapter_camel]]
+[[fuse_adapter_camel]]
 
 ===== Securing an Apache Camel Application
 
diff --git a/securing_apps/topics/oidc/java/fuse/classic-war.adoc b/securing_apps/topics/oidc/java/fuse/classic-war.adoc
index 0a9acb9941..0cd32e656b 100644
--- a/securing_apps/topics/oidc/java/fuse/classic-war.adoc
+++ b/securing_apps/topics/oidc/java/fuse/classic-war.adoc
@@ -1,5 +1,5 @@
 
-[[_fuse_adapter_classic_war]]
+[[fuse_adapter_classic_war]]
 ===== Securing a Classic WAR Application
 
 The needed steps to secure your WAR application are:
diff --git a/securing_apps/topics/oidc/java/fuse/cxf-builtin.adoc b/securing_apps/topics/oidc/java/fuse/cxf-builtin.adoc
index f7660cea24..db703f9607 100644
--- a/securing_apps/topics/oidc/java/fuse/cxf-builtin.adoc
+++ b/securing_apps/topics/oidc/java/fuse/cxf-builtin.adoc
@@ -1,5 +1,5 @@
 
-[[_fuse_adapter_cxf_builtin]]
+[[fuse_adapter_cxf_builtin]]
 ===== Securing an Apache CXF Endpoint on the Default Jetty Engine
 
 Some services automatically come with deployed servlets on startup. One such service is the CXF servlet running in the $$http://localhost:8181/cxf$$ context. Securing such endpoints can be complicated. One approach, which {project_name} is currently using, is ServletReregistrationService, which undeploys a built-in servlet at startup, enabling you to redeploy it on a context secured by {project_name}.
diff --git a/securing_apps/topics/oidc/java/fuse/cxf-separate.adoc b/securing_apps/topics/oidc/java/fuse/cxf-separate.adoc
index 194f7b5251..1ea511c279 100644
--- a/securing_apps/topics/oidc/java/fuse/cxf-separate.adoc
+++ b/securing_apps/topics/oidc/java/fuse/cxf-separate.adoc
@@ -1,5 +1,5 @@
 
-[[_fuse_adapter_cxf_separate]]
+[[fuse_adapter_cxf_separate]]
 ===== Securing an Apache CXF Endpoint on a Separate Jetty Engine
 
 To run your CXF endpoints secured by {project_name} on separate Jetty engines, complete the following steps:
diff --git a/securing_apps/topics/oidc/java/fuse/fuse-admin.adoc b/securing_apps/topics/oidc/java/fuse/fuse-admin.adoc
index 0eafafbac1..9726157937 100644
--- a/securing_apps/topics/oidc/java/fuse/fuse-admin.adoc
+++ b/securing_apps/topics/oidc/java/fuse/fuse-admin.adoc
@@ -1,5 +1,5 @@
 
-[[_fuse_adapter_admin]]
+[[fuse_adapter_admin]]
 ===== Securing Fuse Administration Services
 
 ====== Using SSH Authentication to Fuse Terminal
diff --git a/securing_apps/topics/oidc/java/fuse/hawtio.adoc b/securing_apps/topics/oidc/java/fuse/hawtio.adoc
index 30ee9ebb20..74dedff14b 100644
--- a/securing_apps/topics/oidc/java/fuse/hawtio.adoc
+++ b/securing_apps/topics/oidc/java/fuse/hawtio.adoc
@@ -1,5 +1,5 @@
 
-[[_hawtio]]
+[[hawtio]]
 ===== Securing the Hawtio Administration Console
 
 To secure the Hawtio Administration Console with {project_name}, complete the following steps:
diff --git a/securing_apps/topics/oidc/java/fuse/install-feature.adoc b/securing_apps/topics/oidc/java/fuse/install-feature.adoc
index 9a4e07bd19..eb990da172 100644
--- a/securing_apps/topics/oidc/java/fuse/install-feature.adoc
+++ b/securing_apps/topics/oidc/java/fuse/install-feature.adoc
@@ -1,5 +1,5 @@
 
-[[_fuse_install_feature]]
+[[fuse_install_feature]]
 ===== Installing the Keycloak Feature
 
 You must first install the `keycloak` feature in the JBoss Fuse environment. The keycloak feature includes the Fuse adapter and all third-party dependencies. You can install it either from the Maven repository or from an archive.
diff --git a/securing_apps/topics/oidc/java/fuse/servlet-whiteboard.adoc b/securing_apps/topics/oidc/java/fuse/servlet-whiteboard.adoc
index 535deda2f6..f5ae71302e 100644
--- a/securing_apps/topics/oidc/java/fuse/servlet-whiteboard.adoc
+++ b/securing_apps/topics/oidc/java/fuse/servlet-whiteboard.adoc
@@ -1,5 +1,5 @@
 
-[[_fuse_adapter_servlet_whiteboard]]
+[[fuse_adapter_servlet_whiteboard]]
 ===== Securing a Servlet Deployed as an OSGI Service
 
 You can use this method if you have a servlet class inside your OSGI bundled project that is not deployed as a classic WAR application. Fuse uses Pax Web Whiteboard Extender to deploy such servlets as web applications.
diff --git a/securing_apps/topics/oidc/java/fuse7-adapter.adoc b/securing_apps/topics/oidc/java/fuse7-adapter.adoc
index 0c0d058b57..bef1c6910c 100644
--- a/securing_apps/topics/oidc/java/fuse7-adapter.adoc
+++ b/securing_apps/topics/oidc/java/fuse7-adapter.adoc
@@ -1,5 +1,5 @@
 
-[[_fuse7_adapter]]
+[[fuse7_adapter]]
 ==== JBoss Fuse 7 Adapter
 
 {project_name} supports securing your web applications running inside https://developers.redhat.com/products/fuse/overview/[JBoss Fuse 7].
diff --git a/securing_apps/topics/oidc/java/fuse7/camel.adoc b/securing_apps/topics/oidc/java/fuse7/camel.adoc
index 09976de9cd..784cb2ce7e 100644
--- a/securing_apps/topics/oidc/java/fuse7/camel.adoc
+++ b/securing_apps/topics/oidc/java/fuse7/camel.adoc
@@ -1,5 +1,5 @@
 
-[[_fuse7_adapter_camel]]
+[[fuse7_adapter_camel]]
 ===== Securing an Apache Camel Application
 
 You can secure Apache Camel endpoints implemented with the http://camel.apache.org/undertow.html[camel-undertow] component by injecting the proper security constraints via blueprint and updating the used component to `undertow-keycloak`. You have to add the `OSGI-INF/blueprint/blueprint.xml` file to your Camel application with a similar configuration as below. The roles and security constraint mappings, and adapter configuration might differ slightly depending on your environment and needs.
diff --git a/securing_apps/topics/oidc/java/fuse7/classic-war.adoc b/securing_apps/topics/oidc/java/fuse7/classic-war.adoc
index 324e21bcad..0f97368047 100644
--- a/securing_apps/topics/oidc/java/fuse7/classic-war.adoc
+++ b/securing_apps/topics/oidc/java/fuse7/classic-war.adoc
@@ -1,5 +1,5 @@
 
-[[_fuse7_adapter_classic_war]]
+[[fuse7_adapter_classic_war]]
 ===== Securing a Classic WAR Application
 
 The needed steps to secure your WAR application are:
@@ -68,7 +68,7 @@ For example:
 
 . Contrary to the Fuse 6 adapter, there are no special OSGi imports needed in MANIFEST.MF. 
 
-[[_fuse7_config_external_adapter]]
+[[fuse7_config_external_adapter]]
 ====== Configuration Resolvers
 
 The `keycloak.json` adapter configuration file can be stored inside a bundle,
diff --git a/securing_apps/topics/oidc/java/fuse7/cxf-builtin.adoc b/securing_apps/topics/oidc/java/fuse7/cxf-builtin.adoc
index 154edb35b2..cf76bf5e0d 100644
--- a/securing_apps/topics/oidc/java/fuse7/cxf-builtin.adoc
+++ b/securing_apps/topics/oidc/java/fuse7/cxf-builtin.adoc
@@ -1,5 +1,5 @@
 
-[[_fuse7_adapter_cxf_builtin]]
+[[fuse7_adapter_cxf_builtin]]
 ===== Securing an Apache CXF Endpoint on the Default Undertow Engine
 
 Some services automatically come with deployed servlets on startup. One such service is the CXF servlet running in the $$http://localhost:8181/cxf$$ context. Fuse's Pax Web supports altering existing contexts via configuration admin. This can be used to secure endpoints by {project_name}.
diff --git a/securing_apps/topics/oidc/java/fuse7/cxf-separate.adoc b/securing_apps/topics/oidc/java/fuse7/cxf-separate.adoc
index c0605f7b93..51f22aaf39 100644
--- a/securing_apps/topics/oidc/java/fuse7/cxf-separate.adoc
+++ b/securing_apps/topics/oidc/java/fuse7/cxf-separate.adoc
@@ -1,5 +1,5 @@
 
-[[_fuse7_adapter_cxf_separate]]
+[[fuse7_adapter_cxf_separate]]
 ===== Securing an Apache CXF Endpoint on a Separate Undertow Engine
 
 To run your CXF endpoints secured by {project_name} on a separate Undertow engine, complete the following steps:
diff --git a/securing_apps/topics/oidc/java/fuse7/fuse-admin.adoc b/securing_apps/topics/oidc/java/fuse7/fuse-admin.adoc
index edfafec120..bffe62ad08 100644
--- a/securing_apps/topics/oidc/java/fuse7/fuse-admin.adoc
+++ b/securing_apps/topics/oidc/java/fuse7/fuse-admin.adoc
@@ -1,5 +1,5 @@
 
-[[_fuse7_adapter_admin]]
+[[fuse7_adapter_admin]]
 ===== Securing Fuse Administration Services
 
 ====== Using SSH Authentication to Fuse Terminal
diff --git a/securing_apps/topics/oidc/java/fuse7/hawtio.adoc b/securing_apps/topics/oidc/java/fuse7/hawtio.adoc
index 342829b7b0..8e50f490b9 100644
--- a/securing_apps/topics/oidc/java/fuse7/hawtio.adoc
+++ b/securing_apps/topics/oidc/java/fuse7/hawtio.adoc
@@ -1,5 +1,5 @@
 
-[[_fuse7_hawtio]]
+[[fuse7_hawtio]]
 ===== Securing the Hawtio Administration Console
 
 To secure the Hawtio Administration Console with {project_name}, complete the following steps:
diff --git a/securing_apps/topics/oidc/java/fuse7/install-feature.adoc b/securing_apps/topics/oidc/java/fuse7/install-feature.adoc
index 9f589e1583..faff5daef5 100644
--- a/securing_apps/topics/oidc/java/fuse7/install-feature.adoc
+++ b/securing_apps/topics/oidc/java/fuse7/install-feature.adoc
@@ -1,5 +1,5 @@
 
-[[_fuse7_install_feature]]
+[[fuse7_install_feature]]
 ===== Installing the Keycloak Feature
 
 You must first install the `keycloak-pax-http-undertow` and `keycloak-jaas` features in the JBoss Fuse environment. The `keycloak-pax-http-undertow` feature includes the Fuse adapter and all third-party dependencies. The `keycloak-jaas` contains JAAS module used in realm for SSH and JMX authentication. You can install it either from the Maven repository or from an archive.
diff --git a/securing_apps/topics/oidc/java/fuse7/servlet-whiteboard.adoc b/securing_apps/topics/oidc/java/fuse7/servlet-whiteboard.adoc
index b51ac01b68..a5b5a04c1c 100644
--- a/securing_apps/topics/oidc/java/fuse7/servlet-whiteboard.adoc
+++ b/securing_apps/topics/oidc/java/fuse7/servlet-whiteboard.adoc
@@ -1,5 +1,5 @@
 
-[[_fuse7_adapter_servlet_whiteboard]]
+[[fuse7_adapter_servlet_whiteboard]]
 ===== Securing a Servlet Deployed as an OSGI Service
 
 You can use this method if you have a servlet class inside your OSGI bundled project that is not deployed as a classic WAR application. Fuse uses Pax Web Whiteboard Extender to deploy such servlets as web applications.
diff --git a/securing_apps/topics/oidc/java/installed-adapter.adoc b/securing_apps/topics/oidc/java/installed-adapter.adoc
index 4bec82a002..50b8aa7ed0 100644
--- a/securing_apps/topics/oidc/java/installed-adapter.adoc
+++ b/securing_apps/topics/oidc/java/installed-adapter.adoc
@@ -1,4 +1,4 @@
-[[_installed_adapter]]
+[[installed_adapter]]
 ==== CLI / Desktop Applications
 
 {project_name} supports securing desktop 
@@ -36,7 +36,7 @@ id_token) which can then be used to call backend services.
 
 The `KeycloakInstalled` adapter provides support for renewal of stale tokens.
 
-[[_installed_adapter_installation]]
+[[installed_adapter_installation]]
 ===== Adapter Installation
 
 [source,xml,subs="attributes+"]
diff --git a/securing_apps/topics/oidc/java/jaas.adoc b/securing_apps/topics/oidc/java/jaas.adoc
index 9eb878529a..1175d869c3 100644
--- a/securing_apps/topics/oidc/java/jaas.adoc
+++ b/securing_apps/topics/oidc/java/jaas.adoc
@@ -1,4 +1,4 @@
-[[_jaas_adapter]]
+[[jaas_adapter]]
 ==== JAAS plugin
 
 It's generally not needed to use JAAS for most of the applications, especially if they are HTTP based, and you should most likely choose one of our other adapters.
diff --git a/securing_apps/topics/oidc/java/java-adapter-config.adoc b/securing_apps/topics/oidc/java/java-adapter-config.adoc
index 7567fc719d..a22eb43fa7 100644
--- a/securing_apps/topics/oidc/java/java-adapter-config.adoc
+++ b/securing_apps/topics/oidc/java/java-adapter-config.adoc
@@ -1,5 +1,5 @@
 
-[[_java_adapter_config]]
+[[java_adapter_config]]
 ==== Java Adapter Config
 
 Each Java adapter supported by {project_name} can be configured by a simple JSON file.
diff --git a/securing_apps/topics/oidc/java/jboss-adapter-rpms.adoc b/securing_apps/topics/oidc/java/jboss-adapter-rpms.adoc
index c630869db9..73a9137465 100644
--- a/securing_apps/topics/oidc/java/jboss-adapter-rpms.adoc
+++ b/securing_apps/topics/oidc/java/jboss-adapter-rpms.adoc
@@ -1,4 +1,4 @@
-[[_jboss_adapter_rpm]]
+[[jboss_adapter_rpm]]
 ==== Installing JBoss EAP Adapter from an RPM
 
 Install the EAP 7 Adapters from an RPM:
diff --git a/securing_apps/topics/oidc/java/jboss-adapter.adoc b/securing_apps/topics/oidc/java/jboss-adapter.adoc
index 5efb45cd94..708ff54e5c 100644
--- a/securing_apps/topics/oidc/java/jboss-adapter.adoc
+++ b/securing_apps/topics/oidc/java/jboss-adapter.adoc
@@ -1,4 +1,4 @@
-[[_jboss_adapter]]
+[[jboss_adapter]]
 
 ifeval::[{project_community}==true]
 ==== JBoss EAP/WildFly Adapter
@@ -21,7 +21,7 @@ You can provide an adapter config file in your WAR and change the auth-method to
 Alternatively, you don't have to modify your WAR at all and you can secure it via the {project_name} adapter subsystem configuration in the configuration file, such as `standalone.xml`.
 Both methods are described in this section.
 
-[[_jboss_adapter_installation]]
+[[jboss_adapter_installation]]
 ===== Installing the adapter
 
 Adapters are available as a separate archive depending on what server version you are using.
diff --git a/securing_apps/topics/oidc/java/jetty8-adapter.adoc b/securing_apps/topics/oidc/java/jetty8-adapter.adoc
index 15ff5a1d7e..4c2dadd119 100644
--- a/securing_apps/topics/oidc/java/jetty8-adapter.adoc
+++ b/securing_apps/topics/oidc/java/jetty8-adapter.adoc
@@ -1,12 +1,12 @@
 
-[[_jetty8_adapter]]
+[[jetty8_adapter]]
 ==== Jetty 8.1.x Adapter
 
 Keycloak has a separate adapter for Jetty 8.1.x that you will have to install into your Jetty installation.
 You then have to provide some extra configuration in each WAR you deploy to Jetty.
 Let's go over these steps. 
 
-[[_jetty8_adapter_installation]]
+[[jetty8_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.
diff --git a/securing_apps/topics/oidc/java/jetty9-adapter.adoc b/securing_apps/topics/oidc/java/jetty9-adapter.adoc
index 813397a113..04f09851de 100644
--- a/securing_apps/topics/oidc/java/jetty9-adapter.adoc
+++ b/securing_apps/topics/oidc/java/jetty9-adapter.adoc
@@ -1,12 +1,12 @@
 
-[[_jetty9_adapter]]
+[[jetty9_adapter]]
 ==== Jetty 9.x Adapters
 
 Keycloak has a separate adapter for Jetty 9.1.x, Jetty 9.2.x and Jetty 9.3.x that you will have to install into your Jetty installation.
 You then have to provide some extra configuration in each WAR you deploy to Jetty.
 Let's go over these steps.
 
-[[_jetty9_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.
@@ -31,7 +31,7 @@ Next, you will have to enable the `keycloak` module for your Jetty base:
 $ java -jar $JETTY_HOME/start.jar --add-to-startd=keycloak
 ----
 
-[[_jetty9_per_war]]
+[[jetty9_per_war]]
 ===== Required Per WAR Configuration
 
 This section describes how to secure a WAR directly by adding config and editing files within your WAR package.
diff --git a/securing_apps/topics/oidc/java/logout.adoc b/securing_apps/topics/oidc/java/logout.adoc
index 71d986531d..beb4e61064 100644
--- a/securing_apps/topics/oidc/java/logout.adoc
+++ b/securing_apps/topics/oidc/java/logout.adoc
@@ -1,6 +1,6 @@
 ==== Logout
 
-[[_java_adapter_logout]]
+[[java_adapter_logout]]
 You can log out of a web application in multiple ways.
 For Java EE servlet containers, you can call `HttpServletRequest.logout()`. For other browser applications, you can redirect the browser to
 `$$http://auth-server/auth/realms/{realm-name}/protocol/openid-connect/logout?redirect_uri=encodedRedirectUri$$`, which logs you out if you have an SSO session with your browser.
diff --git a/securing_apps/topics/oidc/java/multi-tenancy.adoc b/securing_apps/topics/oidc/java/multi-tenancy.adoc
index c13396f24e..768b73ecf3 100644
--- a/securing_apps/topics/oidc/java/multi-tenancy.adoc
+++ b/securing_apps/topics/oidc/java/multi-tenancy.adoc
@@ -1,4 +1,4 @@
-[[_multi_tenancy]]
+[[multi_tenancy]]
 ==== Multi Tenancy
 
 Multi Tenancy, in our context, means that a single target application (WAR) can be secured with multiple {project_name} realms. The realms can be located
diff --git a/securing_apps/topics/oidc/java/params_forwarding.adoc b/securing_apps/topics/oidc/java/params_forwarding.adoc
index 88854d682e..04b8b409e9 100644
--- a/securing_apps/topics/oidc/java/params_forwarding.adoc
+++ b/securing_apps/topics/oidc/java/params_forwarding.adoc
@@ -1,4 +1,4 @@
-[[_params_forwarding]]
+[[params_forwarding]]
 ==== Parameters Forwarding
 
 The {project_name}  initial authorization endpoint request has support for various parameters. Most of the parameters are described in
diff --git a/securing_apps/topics/oidc/java/servlet-filter-adapter.adoc b/securing_apps/topics/oidc/java/servlet-filter-adapter.adoc
index 59763d32fd..0c04f592be 100644
--- a/securing_apps/topics/oidc/java/servlet-filter-adapter.adoc
+++ b/securing_apps/topics/oidc/java/servlet-filter-adapter.adoc
@@ -1,4 +1,4 @@
-[[_servlet_filter_adapter]]
+[[servlet_filter_adapter]]
 ==== Java Servlet Filter Adapter
 
 If you are deploying your Java Servlet application on a platform where there is no {project_name} adapter you opt to use the servlet filter adapter.
diff --git a/securing_apps/topics/oidc/java/spring-boot-adapter.adoc b/securing_apps/topics/oidc/java/spring-boot-adapter.adoc
index 1963530d1b..9ad8c76abf 100644
--- a/securing_apps/topics/oidc/java/spring-boot-adapter.adoc
+++ b/securing_apps/topics/oidc/java/spring-boot-adapter.adoc
@@ -1,10 +1,10 @@
-[[_spring_boot_adapter]]
+[[spring_boot_adapter]]
 ==== Spring Boot Adapter
 
 To be able to secure Spring Boot apps you must add the Keycloak Spring Boot adapter JAR to your app.
 You then have to provide some extra configuration via normal Spring Boot configuration (`application.properties`).  Let's go over these steps.
 
-[[_spring_boot_adapter_installation]]
+[[spring_boot_adapter_installation]]
 ===== Adapter Installation
 
 The Keycloak Spring Boot adapter takes advantage of Spring Boot's autoconfiguration so all you need to do is add the Keycloak Spring Boot starter to your project.
@@ -50,7 +50,7 @@ Currently the following embedded containers are supported and do not require any
 * Undertow
 * Jetty
 
-[[_spring_boot_adapter_configuration]]
+[[spring_boot_adapter_configuration]]
 ===== Required Spring Boot Adapter Configuration
 
 This section describes how to configure your Spring Boot app to use Keycloak.
diff --git a/securing_apps/topics/oidc/java/spring-security-adapter.adoc b/securing_apps/topics/oidc/java/spring-security-adapter.adoc
index f95b4c2331..3326836fd7 100644
--- a/securing_apps/topics/oidc/java/spring-security-adapter.adoc
+++ b/securing_apps/topics/oidc/java/spring-security-adapter.adoc
@@ -1,4 +1,4 @@
-[[_spring_security_adapter]]
+[[spring_security_adapter]]
 ==== Spring Security Adapter
 
 To secure an application with Spring Security and Keycloak, add this adapter as a dependency to your project.
diff --git a/securing_apps/topics/oidc/java/tomcat-adapter.adoc b/securing_apps/topics/oidc/java/tomcat-adapter.adoc
index 84c4980445..d51f7e3b62 100644
--- a/securing_apps/topics/oidc/java/tomcat-adapter.adoc
+++ b/securing_apps/topics/oidc/java/tomcat-adapter.adoc
@@ -1,12 +1,12 @@
 
-[[_tomcat_adapter]]
+[[tomcat_adapter]]
 ==== Tomcat 6, 7 and 8 Adapters
 
 To be able to secure WAR apps deployed on Tomcat 6, 7 and 8 you must install the Keycloak Tomcat 6, 7 or 8 adapter into your Tomcat installation.
 You then have to provide some extra configuration in each WAR you deploy to Tomcat.
 Let's go over these steps. 
 
-[[_tomcat_adapter_installation]]
+[[tomcat_adapter_installation]]
 ===== Adapter Installation
 
 Adapters are no longer included with the appliance or war distribution.
diff --git a/securing_apps/topics/oidc/javascript-adapter.adoc b/securing_apps/topics/oidc/javascript-adapter.adoc
index 3f779c5581..ae8f3b7173 100644
--- a/securing_apps/topics/oidc/javascript-adapter.adoc
+++ b/securing_apps/topics/oidc/javascript-adapter.adoc
@@ -1,4 +1,4 @@
-[[_javascript_adapter]]
+[[javascript_adapter]]
 === JavaScript Adapter
 
 {project_name} comes with a client-side JavaScript library that can be used to secure HTML5/JavaScript applications. The JavaScript adapter has built-in support for Cordova applications.
@@ -118,7 +118,7 @@ This feature can be disabled by setting `checkLoginIframe: false` in the options
 You should not rely on looking at this cookie directly. Its format can change and it's also associated with the URL of the {project_name} server, not
 your application.
 
-[[_javascript_implicit_flow]]
+[[javascript_implicit_flow]]
 ==== Implicit and Hybrid Flow
 
 By default, the JavaScript adapter uses the https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth[Authorization Code] flow.
diff --git a/securing_apps/topics/oidc/keycloak-gatekeeper.adoc b/securing_apps/topics/oidc/keycloak-gatekeeper.adoc
index efea62755a..391dc1d344 100644
--- a/securing_apps/topics/oidc/keycloak-gatekeeper.adoc
+++ b/securing_apps/topics/oidc/keycloak-gatekeeper.adoc
@@ -1,4 +1,4 @@
-[[_keycloak_generic_adapter]]
+[[keycloak_generic_adapter]]
 === {generic_adapter_name_full}
 
 {project_name} provides a Go programming language adapter for use with OpenID Connect (OIDC) that supports both access tokens in a browser cookie or bearer tokens.
diff --git a/securing_apps/topics/oidc/mod-auth-openidc.adoc b/securing_apps/topics/oidc/mod-auth-openidc.adoc
index fe113f55ce..a8253f4ba9 100644
--- a/securing_apps/topics/oidc/mod-auth-openidc.adoc
+++ b/securing_apps/topics/oidc/mod-auth-openidc.adoc
@@ -1,4 +1,4 @@
-[[_mod_auth_openidc]]
+[[mod_auth_openidc]]
 ==== mod_auth_openidc Apache HTTPD Module
 
 The https://github.com/zmartzone/mod_auth_openidc[mod_auth_openidc] is an Apache HTTP plugin for OpenID Connect. If your language/environment supports using Apache HTTPD
diff --git a/securing_apps/topics/oidc/nodejs-adapter.adoc b/securing_apps/topics/oidc/nodejs-adapter.adoc
index 6ab1677e23..f082816061 100644
--- a/securing_apps/topics/oidc/nodejs-adapter.adoc
+++ b/securing_apps/topics/oidc/nodejs-adapter.adoc
@@ -1,4 +1,4 @@
-[[_nodejs_adapter]]
+[[nodejs_adapter]]
 === Node.js Adapter
 
 {project_name} provides a Node.js adapter built on top of https://github.com/senchalabs/connect[Connect] to protect server-side JavaScript apps - the goal was to be flexible enough to integrate with frameworks like https://expressjs.com/[Express.js].
diff --git a/securing_apps/topics/oidc/oidc-generic.adoc b/securing_apps/topics/oidc/oidc-generic.adoc
index 1baec96a63..a7f4c6a899 100644
--- a/securing_apps/topics/oidc/oidc-generic.adoc
+++ b/securing_apps/topics/oidc/oidc-generic.adoc
@@ -55,7 +55,7 @@ The user agent can be redirected to the endpoint, in which case the active user
 
 The endpoint can also be invoked directly by the application. To invoke this endpoint directly the refresh token needs to be included as well as the credentials required to authenticate the client.
 
-[[_certificate_endpoint]]
+[[certificate_endpoint]]
 ===== Certificate Endpoint
 ....
 /realms/{realm-name}/protocol/openid-connect/certs
@@ -63,7 +63,7 @@ The endpoint can also be invoked directly by the application. To invoke this end
 
 The certificate endpoint returns the public keys enabled by the realm, encoded as a JSON Web Key (JWK). Depending on the realm settings there can be one or more keys enabled for verifying tokens. For more information see the link:{adminguide_link}[{adminguide_name}] and the https://tools.ietf.org/html/rfc7517[JSON Web Key specification].
 
-[[_token_introspection_endpoint]]
+[[token_introspection_endpoint]]
 ===== Introspection Endpoint
 ....
 /realms/{realm-name}/protocol/openid-connect/token/introspect
@@ -122,7 +122,7 @@ browser history. This is somewhat mitigated by using short expiration for Access
 
 For more details refer to the https://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_flow]]
 ===== Resource Owner Password Credentials
 
 Resource Owner Password Credentials, referred to as Direct Grant in {project_name}, allows exchanging user credentials for tokens. It's not recommended
@@ -182,13 +182,13 @@ In production for web applications always use `https` for all redirect URIs. Do
 
 There's also a few special redirect URIs:
 
-[[_installed_applications_url]]
+[[installed_applications_url]]
 `$$http://localhost$$`::
 
   This redirect URI is useful for native applications and allows the native application to create a web server on a random port that can be used to obtain the
   authorization code. This redirect uri allows any port.
 
-[[_installed_applications_urn]]
+[[installed_applications_urn]]
 `urn:ietf:wg:oauth:2.0:oob`::
 
   If its not possible to start a web server in the client (or a browser is not available) it is possible to use the special `urn:ietf:wg:oauth:2.0:oob` redirect uri.
diff --git a/securing_apps/topics/overview/supported-protocols.adoc b/securing_apps/topics/overview/supported-protocols.adoc
index 25a0300eb4..6ef68fc744 100644
--- a/securing_apps/topics/overview/supported-protocols.adoc
+++ b/securing_apps/topics/overview/supported-protocols.adoc
@@ -1,4 +1,4 @@
-[[_supported_protocols]]
+[[supported_protocols]]
 
 === Supported Protocols
 
diff --git a/securing_apps/topics/saml/java/general-config.adoc b/securing_apps/topics/saml/java/general-config.adoc
index fdfa572887..cb3a8dcda5 100644
--- a/securing_apps/topics/saml/java/general-config.adoc
+++ b/securing_apps/topics/saml/java/general-config.adoc
@@ -1,4 +1,4 @@
-[[_saml-general-config]]
+[[saml-general-config]]
 
 ==== General Adapter Config
 
diff --git a/securing_apps/topics/saml/java/general-config/idp_httpclient_subelement.adoc b/securing_apps/topics/saml/java/general-config/idp_httpclient_subelement.adoc
index 521568fed0..093a66ee7e 100644
--- a/securing_apps/topics/saml/java/general-config/idp_httpclient_subelement.adoc
+++ b/securing_apps/topics/saml/java/general-config/idp_httpclient_subelement.adoc
@@ -1,4 +1,4 @@
-[[_sp-idp-httpclient]]
+[[sp-idp-httpclient]]
 
 ===== IDP HttpClient sub element
 
diff --git a/securing_apps/topics/saml/java/general-config/idp_keys_subelement.adoc b/securing_apps/topics/saml/java/general-config/idp_keys_subelement.adoc
index af36c64d09..1bfec6740f 100644
--- a/securing_apps/topics/saml/java/general-config/idp_keys_subelement.adoc
+++ b/securing_apps/topics/saml/java/general-config/idp_keys_subelement.adoc
@@ -1,4 +1,4 @@
-[[_sp-idp-keys]]
+[[sp-idp-keys]]
 
 ===== IDP Keys sub element
 
@@ -7,7 +7,7 @@ It is defined in the same way as the <<_saml-sp-keys,SP's Keys element>>.
 But again, you only have to define one certificate or public key reference. Note that, if both IDP and SP are realized by
 {project_name} server and adapter, respectively, there is no need to specify the keys for signature validation, see below.
 
-[[_sp-idp-keys-automatic]]
+[[sp-idp-keys-automatic]]
 It is possible to configure SP to obtain public keys for IDP signature validation
 from published certificates automatically, provided both SP and IDP are
 implemented by {project_name}.
diff --git a/securing_apps/topics/saml/java/general-config/idp_singlesignonservice_subelement.adoc b/securing_apps/topics/saml/java/general-config/idp_singlesignonservice_subelement.adoc
index 3645cae259..1652fa1276 100644
--- a/securing_apps/topics/saml/java/general-config/idp_singlesignonservice_subelement.adoc
+++ b/securing_apps/topics/saml/java/general-config/idp_singlesignonservice_subelement.adoc
@@ -1,4 +1,4 @@
-[[_sp-idp-singlesignonservice]]
+[[sp-idp-singlesignonservice]]
 
 ===== IDP SingleSignOnService sub element
 
diff --git a/securing_apps/topics/saml/java/general-config/sp-keys.adoc b/securing_apps/topics/saml/java/general-config/sp-keys.adoc
index a36440a019..3b6dd785c6 100644
--- a/securing_apps/topics/saml/java/general-config/sp-keys.adoc
+++ b/securing_apps/topics/saml/java/general-config/sp-keys.adoc
@@ -1,4 +1,4 @@
-[[_saml-sp-keys]]
+[[saml-sp-keys]]
 
 ===== Service Provider Keys and Key Elements
 
diff --git a/securing_apps/topics/saml/java/general-config/sp-keys/keystore_element.adoc b/securing_apps/topics/saml/java/general-config/sp-keys/keystore_element.adoc
index f00f4ffd04..302c1fbded 100644
--- a/securing_apps/topics/saml/java/general-config/sp-keys/keystore_element.adoc
+++ b/securing_apps/topics/saml/java/general-config/sp-keys/keystore_element.adoc
@@ -1,4 +1,4 @@
-[[_saml-keystore]]
+[[saml-keystore]]
 
 ====== KeyStore element
 
diff --git a/securing_apps/topics/saml/java/jboss-adapter/jboss-adapter-rpms.adoc b/securing_apps/topics/saml/java/jboss-adapter/jboss-adapter-rpms.adoc
index 3d07b83f85..4eb21dfaae 100644
--- a/securing_apps/topics/saml/java/jboss-adapter/jboss-adapter-rpms.adoc
+++ b/securing_apps/topics/saml/java/jboss-adapter/jboss-adapter-rpms.adoc
@@ -1,4 +1,4 @@
-[[_jboss_adapter_rpm_saml]]
+[[jboss_adapter_rpm_saml]]
 ==== Installing JBoss EAP Adapter from an RPM
 
 Install the EAP 7 Adapters from an RPM:
diff --git a/securing_apps/topics/saml/java/jboss-adapter/jboss_adapter_installation.adoc b/securing_apps/topics/saml/java/jboss-adapter/jboss_adapter_installation.adoc
index b6661ffdac..7244af09ab 100644
--- a/securing_apps/topics/saml/java/jboss-adapter/jboss_adapter_installation.adoc
+++ b/securing_apps/topics/saml/java/jboss-adapter/jboss_adapter_installation.adoc
@@ -1,5 +1,5 @@
 
-[[_saml-jboss-adapter-installation]]
+[[saml-jboss-adapter-installation]]
 ===== Adapter Installation
 
 Each adapter is a separate download on the {project_name} download site.
@@ -26,6 +26,8 @@ Install on JBoss EAP 6.x:
 $ cd $JBOSS_HOME
 $ unzip keycloak-saml-eap6-adapter-dist.zip
 ----
+
+These zip files create new JBoss Modules specific to the WildFly/JBoss EAP SAML Adapter within your WildFly or JBoss EAP distro.
 endif::[]
 
 ifeval::[{project_product}==true]
@@ -44,11 +46,11 @@ Install on JBoss EAP 6.x:
 $ cd $EAP_HOME
 $ unzip rh-sso-saml-eap6-adapter.zip
 ----
+
+These zip files create new JBoss Modules specific to the JBoss EAP SAML Adapter within your JBoss EAP distro.
 endif::[]
 
 
-These zip files create new JBoss Modules specific to the WildFly/JBoss EAP SAML Adapter within your WildFly or JBoss EAP distro.
-
 After adding the modules, you must then enable the {project_name} SAML 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.
diff --git a/securing_apps/topics/saml/java/jetty-adapter.adoc b/securing_apps/topics/saml/java/jetty-adapter.adoc
index 20945e3216..aa58dd63b7 100644
--- a/securing_apps/topics/saml/java/jetty-adapter.adoc
+++ b/securing_apps/topics/saml/java/jetty-adapter.adoc
@@ -1,4 +1,4 @@
-[[_jetty_saml_adapter]]
+[[jetty_saml_adapter]]
 
 ==== Jetty SAML Adapters
 
diff --git a/securing_apps/topics/saml/java/jetty-adapter/jetty9_installation.adoc b/securing_apps/topics/saml/java/jetty-adapter/jetty9_installation.adoc
index 893b6bd809..b638c84ac3 100644
--- a/securing_apps/topics/saml/java/jetty-adapter/jetty9_installation.adoc
+++ b/securing_apps/topics/saml/java/jetty-adapter/jetty9_installation.adoc
@@ -1,4 +1,4 @@
-[[_jetty9_saml_adapter_installation]]
+[[jetty9_saml_adapter_installation]]
 
 ===== Jetty 9 Adapter Installation
 
diff --git a/securing_apps/topics/saml/java/jetty-adapter/jetty9_per_war_config.adoc b/securing_apps/topics/saml/java/jetty-adapter/jetty9_per_war_config.adoc
index c1a9d5fc35..e79068a250 100644
--- a/securing_apps/topics/saml/java/jetty-adapter/jetty9_per_war_config.adoc
+++ b/securing_apps/topics/saml/java/jetty-adapter/jetty9_per_war_config.adoc
@@ -1,5 +1,5 @@
 
-[[_saml-jetty9-per-war]]
+[[saml-jetty9-per-war]]
 ===== Jetty 9 Per WAR Configuration
 
 This section describes how to secure a WAR directly by adding config and editing files within your WAR package. 
diff --git a/securing_apps/topics/saml/java/logout.adoc b/securing_apps/topics/saml/java/logout.adoc
index 40fb110d6a..bfde99b13f 100644
--- a/securing_apps/topics/saml/java/logout.adoc
+++ b/securing_apps/topics/saml/java/logout.adoc
@@ -5,7 +5,7 @@ For Java EE servlet containers, you can call `HttpServletRequest.logout()`. For
 the browser at any url of your web application that has a security constraint and pass in a query parameter GLO, i.e. `$$http://myapp?GLO=true$$`.
 This will log you out if you have an SSO session with your browser. 
 
-[[_saml_logout_in_cluster]]
+[[saml_logout_in_cluster]]
 ===== Logout in Clustered Environment
 
 Internally, the SAML adapter stores a mapping between the SAML session index, principal name (when known), and HTTP session ID.
@@ -48,7 +48,7 @@ Currently, to provide reliable service, it is recommended to use replicated cach
 Using distributed cache may lead to results where the SAML logout request would land to a node with no access
 to SAML session index to HTTP session mapping which would lead to unsuccessful logout.
 
-[[_saml_logout_in_cross_dc]]
+[[saml_logout_in_cross_dc]]
 ===== Logout in Cross DC Scenario
 
 The cross DC scenario only applies to WildFly 10 and higher, and EAP 7 and higher.
diff --git a/securing_apps/topics/saml/java/multi-tenancy.adoc b/securing_apps/topics/saml/java/multi-tenancy.adoc
index e94e8dab08..2e87f08213 100644
--- a/securing_apps/topics/saml/java/multi-tenancy.adoc
+++ b/securing_apps/topics/saml/java/multi-tenancy.adoc
@@ -1,4 +1,4 @@
-[[_saml_multi_tenancy]]
+[[saml_multi_tenancy]]
 ==== Multi Tenancy
 
 SAML offers the same functionality as OIDC for <<_multi_tenancy,Multi Tenancy>>, meaning that a single target application (WAR) can be secured with multiple {project_name} realms. The realms can be located on the same {project_name} instance or on different instances.
diff --git a/securing_apps/topics/saml/java/saml-jboss-adapter.adoc b/securing_apps/topics/saml/java/saml-jboss-adapter.adoc
index 722139552d..7997694ab3 100644
--- a/securing_apps/topics/saml/java/saml-jboss-adapter.adoc
+++ b/securing_apps/topics/saml/java/saml-jboss-adapter.adoc
@@ -1,4 +1,4 @@
-[[_saml_jboss_adapter]]
+[[saml_jboss_adapter]]
 
 ifeval::[{project_community}==true]
 ==== JBoss EAP/WildFly Adapter
diff --git a/securing_apps/topics/saml/java/tomcat-adapter.adoc b/securing_apps/topics/saml/java/tomcat-adapter.adoc
index a6540451fe..6b29a3d543 100644
--- a/securing_apps/topics/saml/java/tomcat-adapter.adoc
+++ b/securing_apps/topics/saml/java/tomcat-adapter.adoc
@@ -1,4 +1,4 @@
-[[_saml-tomcat-adapter]]
+[[saml-tomcat-adapter]]
 
 ==== Tomcat SAML adapters
 
diff --git a/securing_apps/topics/saml/java/tomcat-adapter/tomcat_adapter_installation.adoc b/securing_apps/topics/saml/java/tomcat-adapter/tomcat_adapter_installation.adoc
index 9f6ecf19dc..857c0220f1 100644
--- a/securing_apps/topics/saml/java/tomcat-adapter/tomcat_adapter_installation.adoc
+++ b/securing_apps/topics/saml/java/tomcat-adapter/tomcat_adapter_installation.adoc
@@ -1,5 +1,5 @@
 
-[[_saml-tomcat-adapter-installation]]
+[[saml-tomcat-adapter-installation]]
 ===== Adapter Installation
 
 Adapters are no longer included with the appliance or war distribution.
diff --git a/securing_apps/topics/saml/mod-auth-mellon.adoc b/securing_apps/topics/saml/mod-auth-mellon.adoc
index 6243486b38..f909b062eb 100644
--- a/securing_apps/topics/saml/mod-auth-mellon.adoc
+++ b/securing_apps/topics/saml/mod-auth-mellon.adoc
@@ -1,4 +1,4 @@
-[[_mod_auth_mellon]]
+[[mod_auth_mellon]]
 
 === mod_auth_mellon Apache HTTPD Module
 
diff --git a/securing_apps/topics/token-exchange/token-exchange.adoc b/securing_apps/topics/token-exchange/token-exchange.adoc
index 37aba88c9e..4e00be8c40 100644
--- a/securing_apps/topics/token-exchange/token-exchange.adoc
+++ b/securing_apps/topics/token-exchange/token-exchange.adoc
@@ -1,5 +1,5 @@
 
-[[_token-exchange]]
+[[token-exchange]]
 
 == Token Exchange
 
@@ -121,7 +121,7 @@ claims and permissions within the access token.  Other reasons this type of exch
 need to perform a "permission downgrade" where your app needs to invoke on a less trusted app and you don't want
 to propagate your current access token.
 
-[[_client_to_client_permission]]
+[[client_to_client_permission]]
 ==== Granting Permission for the Exchange
 
 Clients that want to exchange tokens for a different client need to be authorized in the admin console to do so.
@@ -206,7 +206,7 @@ have been performed with the same user session as the internal token you are exc
 If the account is not linked, the exchange response will contain a link you can use to establish it.  This is
 discussed more in the <<_internal_external_making_request, Making the Request>> section.
 
-[[_grant_permission_external_exchange]]
+[[grant_permission_external_exchange]]
 ==== Granting Permission for the Exchange
 
 Internal to external token exchange requests will be denied with a 403, Forbidden response until you grant
@@ -243,7 +243,7 @@ image:{project_images}/exchange-idp-apply-policy.png[]
 Your client now has permission to invoke.  If you do not do this correctly, you will get a 403 Forbidden response if you
 try to make an exchange.
 
-[[_internal_external_making_request]]
+[[internal_external_making_request]]
 ==== Making the Request
 
 When your client is exchanging an existing internal token to an external one, you must provide the
diff --git a/server_admin/topics/admin-cli.adoc b/server_admin/topics/admin-cli.adoc
index 93b92f04e5..3fb16b32d1 100644
--- a/server_admin/topics/admin-cli.adoc
+++ b/server_admin/topics/admin-cli.adoc
@@ -884,7 +884,7 @@ $ kcadm.sh get clients/c7b8547f-e748-4333-95d0-410b76b3f4a3/installation/provide
 ----
 
 [discrete]
-==== Getting a WildFly subsystem adapter configuration for a specific client
+==== Getting a {appserver_name} subsystem adapter configuration for a specific client
 
 Use a client's ID to construct an endpoint URI that targets a specific client, such as [filename]`clients/ID/installation/providers/keycloak-oidc-jboss-subsystem`.
 
diff --git a/server_admin/topics/authentication/x509.adoc b/server_admin/topics/authentication/x509.adoc
index a9f330712e..52781fc4a8 100644
--- a/server_admin/topics/authentication/x509.adoc
+++ b/server_admin/topics/authentication/x509.adoc
@@ -8,7 +8,7 @@ A typical workflow is as follows:
 
 - A client sends an authentication request over SSL/TLS channel
 - During SSL/TLS handshake, the server and the client exchange their x.509/v3 certificates
-- The container (WildFly) validates the certificate PKIX path and the certificate expiration
+- The container ({appserver_name}) validates the certificate PKIX path and the certificate expiration
 - The x.509 client certificate authenticator validates the client certificate as follows:
 * Optionally checks the certificate revocation status using CRL and/or CRL Distribution Points
 * Optionally checks the Certificate revocation status using OCSP (Online Certificate Status Protocol)
@@ -54,11 +54,11 @@ Other Features: Extended Certificate Validation::
 
 ==== Enable X.509 Client Certificate User Authentication
 
-The following sections describe how to configure WildFly/Undertow and the {project_name} Server to enable X.509 client certificate authentication.
+The following sections describe how to configure {appserver_name}/Undertow and the {project_name} Server to enable X.509 client certificate authentication.
 
 [[_enable-mtls-wildfly]]
-Enable mutual SSL in WildFly::
-See link:https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-EnableSSL[Enable SSL] and link:https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-%7B%7B%3Cssl%2F%3E%7D%7D[SSL] for the instructions how to enable SSL in WildFly.
+Enable mutual SSL in {appserver_name}::
+See link:https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-EnableSSL[Enable SSL] and link:https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-%7B%7B%3Cssl%2F%3E%7D%7D[SSL] for the instructions how to enable SSL in {appserver_name}.
 
 * Open {project_dirref}/standalone/configuration/standalone.xml and add a new realm:
 ```xml
@@ -113,7 +113,7 @@ The password to open the truststore
 
 Enable https listener::
 
-See link:https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-HTTPSlistener[HTTPS Listener] for the instructions how to enable HTTPS in WildFly.
+See link:https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-HTTPSlistener[HTTPS Listener] for the instructions how to enable HTTPS in {appserver_name}.
 
 * Add the <https-listener> element as shown below:
 
diff --git a/server_admin/topics/migrate_themes-changes-72.adoc b/server_admin/topics/migrate_themes-changes-72.adoc
new file mode 100644
index 0000000000..c1838c5109
--- /dev/null
+++ b/server_admin/topics/migrate_themes-changes-72.adoc
@@ -0,0 +1,51 @@
+===== Theme changes RH-SSO 7.2
+
+**Templates**
+
+* Account: account.ftl
+* Account: applications.ftl
+* Account: federatedIdentity.ftl
+* Account: password.ftl
+* Account: sessions.ftl
+* Account: template.ftl
+* Account: totp.ftl
+* Admin: index.ftl
+* Email: email-test.ftl (new)
+* Email: email-verification.ftl
+* Email: event-login_error.ftl
+* Email: event-removed_totp.ftl
+* Email: event-update_password.ftl
+* Email: event-update_totp.ftl
+* Email: executeActions.ftl
+* Email: identity-provider-link.ftl
+* Email: password-reset.ftl
+* Login: bypass_kerberos.ftl (removed)
+* Login: error.ftl
+* Login: info.ftl
+* Login: login-config-totp.ftl
+* Login: login-idp-link-email.ftl
+* Login: login-oauth-grant.ftl
+* Login: login-page-expired.ftl (new)
+* Login: login-reset-password.ftl
+* Login: login-totp.ftl
+* Login: login-update-password.ftl
+* Login: login-update-profile.ftl
+* Login: login-verify-email.ftl
+* Login: login-x509-info.ftl (new)
+* Login: login.ftl (new)
+* Login: register.ftl (new)
+* Login: template.ftl (new)
+* Login: terms.ftl (new)
+
+**Messages**
+
+* Account: messages_en.properties
+* Admin: admin-messages_en.properties
+* Admin: messages_en.properties
+* Email: messages_en.properties
+* Login: messages_en.properties
+
+**Styles**
+
+* Account: account.css
+* Login: login.css