fixed Wildfly mentions and faulty links with underscores
This commit is contained in:
Matthew Helmke
Hynek Mlnařík
parent
9431096112
commit
a8cdbc3ca3
64 changed files with 155 additions and 102 deletions
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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].
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
|
||||
[[_adapter_error_handling]]
|
||||
[[adapter_error_handling]]
|
||||
==== Error Handling
|
||||
|
||||
{project_name} has some error handling facilities for servlet based client adapters.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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].
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
[[_fuse_adapter_camel]]
|
||||
[[fuse_adapter_camel]]
|
||||
|
||||
===== Securing an Apache Camel Application
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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}.
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
|
||||
[[_fuse_adapter_admin]]
|
||||
[[fuse_adapter_admin]]
|
||||
===== Securing Fuse Administration Services
|
||||
|
||||
====== Using SSH Authentication to Fuse Terminal
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
|
||||
[[_hawtio]]
|
||||
[[hawtio]]
|
||||
===== Securing the Hawtio Administration Console
|
||||
|
||||
To secure the Hawtio Administration Console with {project_name}, complete the following steps:
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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].
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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,
|
||||
|
|
|
|||
|
|
@ -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}.
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
|
||||
[[_fuse7_adapter_admin]]
|
||||
[[fuse7_adapter_admin]]
|
||||
===== Securing Fuse Administration Services
|
||||
|
||||
====== Using SSH Authentication to Fuse Terminal
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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+"]
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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].
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
[[_supported_protocols]]
|
||||
[[supported_protocols]]
|
||||
|
||||
=== Supported Protocols
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
[[_saml-general-config]]
|
||||
[[saml-general-config]]
|
||||
|
||||
==== General Adapter Config
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
[[_sp-idp-httpclient]]
|
||||
[[sp-idp-httpclient]]
|
||||
|
||||
===== IDP HttpClient sub element
|
||||
|
||||
|
|
|
|||
|
|
@ -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}.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
[[_sp-idp-singlesignonservice]]
|
||||
[[sp-idp-singlesignonservice]]
|
||||
|
||||
===== IDP SingleSignOnService sub element
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
[[_saml-sp-keys]]
|
||||
[[saml-sp-keys]]
|
||||
|
||||
===== Service Provider Keys and Key Elements
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
[[_saml-keystore]]
|
||||
[[saml-keystore]]
|
||||
|
||||
====== KeyStore element
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
[[_jetty_saml_adapter]]
|
||||
[[jetty_saml_adapter]]
|
||||
|
||||
==== Jetty SAML Adapters
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
[[_jetty9_saml_adapter_installation]]
|
||||
[[jetty9_saml_adapter_installation]]
|
||||
|
||||
===== Jetty 9 Adapter Installation
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
[[_saml_jboss_adapter]]
|
||||
[[saml_jboss_adapter]]
|
||||
|
||||
ifeval::[{project_community}==true]
|
||||
==== JBoss EAP/WildFly Adapter
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
[[_saml-tomcat-adapter]]
|
||||
[[saml-tomcat-adapter]]
|
||||
|
||||
==== Tomcat SAML adapters
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
[[_mod_auth_mellon]]
|
||||
[[mod_auth_mellon]]
|
||||
|
||||
=== mod_auth_mellon Apache HTTPD Module
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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`.
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
51
server_admin/topics/migrate_themes-changes-72.adoc
Normal file
51
server_admin/topics/migrate_themes-changes-72.adoc
Normal file
|
|
@ -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
|
||||
Loading…
Reference in a new issue