diff --git a/securing_apps/topics/client-registration.adoc b/securing_apps/topics/client-registration.adoc index 8d11cecaf7c..7c45920c152 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 210dc94d039..9bf271a17b5 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 cb9a5c59667..7c479e9b50b 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 b85fa5419fe..8b2e0e9a1c1 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 9c09d594e49..8f292eabda7 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 74f9c4dc426..2ad229b699b 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 af5b5041edd..420bfffc17d 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 0a9acb9941d..0cd32e656ba 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 f7660cea24e..db703f9607e 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 194f7b52518..1ea511c2795 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 0eafafbac1d..97261579373 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 30ee9ebb202..74dedff14bd 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 9a4e07bd194..eb990da1720 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 535deda2f6a..f5ae71302ec 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 0c0d058b574..bef1c6910ce 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 09976de9cdc..784cb2ce7e2 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 324e21bcadf..0f973680476 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 154edb35b2a..cf76bf5e0db 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 c0605f7b934..51f22aaf397 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 edfafec1202..bffe62ad08a 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 342829b7b01..8e50f490b9f 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 9f589e1583e..faff5daef56 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 b51ac01b686..a5b5a04c1cd 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 4bec82a002d..50b8aa7ed01 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 9eb878529a4..1175d869c34 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 7567fc719da..a22eb43fa71 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 c630869db97..73a91374652 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 5efb45cd949..708ff54e5c6 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 15ff5a1d7ed..4c2dadd1193 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 813397a1134..04f09851def 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 71d986531d0..beb4e61064c 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 c13396f24ed..768b73ecf37 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 88854d682ef..04b8b409e91 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 59763d32fdf..0c04f592be6 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 1963530d1bb..9ad8c76abf1 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 f95b4c23317..3326836fd77 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 84c4980445c..d51f7e3b621 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 3f779c55819..ae8f3b71734 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 efea62755a0..391dc1d3449 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 fe113f55cee..a8253f4ba9a 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 6ab1677e23d..f082816061d 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 1baec96a63a..a7f4c6a8998 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 25a0300eb42..6ef68fc744c 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 fdfa572887a..cb3a8dcda5f 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 521568fed03..093a66ee7e4 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 af36c64d096..1bfec6740f8 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 3645cae259e..1652fa12769 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 a36440a0192..3b6dd785c61 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 f00f4ffd04f..302c1fbdedd 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 3d07b83f850..4eb21dfaae9 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 b6661ffdac9..7244af09abc 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 20945e3216d..aa58dd63b7d 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 893b6bd809b..b638c84ac33 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 c1a9d5fc35d..e79068a2508 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 40fb110d6ac..bfde99b13fc 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 e94e8dab08e..2e87f082132 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 722139552d2..7997694ab3d 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 a6540451fe6..6b29a3d543a 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 9f6ecf19dcb..857c0220f13 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 6243486b380..f909b062eb5 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 37aba88c9e1..4e00be8c40f 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 93b92f04e51..3fb16b32d14 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 a9f330712ed..52781fc4a88 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 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 00000000000..c1838c51096 --- /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