From b26a91c7a2ee652680c0c0b99a26a61f28890223 Mon Sep 17 00:00:00 2001 From: Peter Skopek Date: Fri, 11 Dec 2020 23:04:38 +0100 Subject: [PATCH] KEYCLOAK-16522 fix test issues (external links and anchor) (#44) --- .../topics/oidc/java/java-adapter-config.adoc | 2 +- securing_apps/topics/oidc/java/jetty9-adapter.adoc | 2 +- .../topics/roles-groups/con-default-roles.adoc | 13 +++++++++++++ .../topics/clustering/sticky-sessions.adoc | 2 +- .../topics/operating-mode/crossdc.adoc | 5 ++--- tests/src/test/resources/ignored-links | 1 + upgrading/topics/keycloak/changes.adoc | 2 +- 7 files changed, 20 insertions(+), 7 deletions(-) create mode 100644 server_admin/topics/roles-groups/con-default-roles.adoc diff --git a/securing_apps/topics/oidc/java/java-adapter-config.adoc b/securing_apps/topics/oidc/java/java-adapter-config.adoc index c5d29556e3..ae9c0cacf6 100644 --- a/securing_apps/topics/oidc/java/java-adapter-config.adoc +++ b/securing_apps/topics/oidc/java/java-adapter-config.adoc @@ -284,4 +284,4 @@ verify-token-audience:: If set to `true`, then during authentication with the bearer token, the adapter will verify whether the token contains this client name (resource) as an audience. The option is especially useful for services, which primarily serve requests authenticated by the bearer token. This is set to `false` by default, however for improved security, it is recommended to enable this. - See link:{adminguide_link}#_audience[Audience Support] for more details about audience support. + See link:{adminguide_link}#audience-support[Audience Support] for more details about audience support. diff --git a/securing_apps/topics/oidc/java/jetty9-adapter.adoc b/securing_apps/topics/oidc/java/jetty9-adapter.adoc index 6cd9921159..27265b0cbd 100644 --- a/securing_apps/topics/oidc/java/jetty9-adapter.adoc +++ b/securing_apps/topics/oidc/java/jetty9-adapter.adoc @@ -12,7 +12,7 @@ Let's go over these steps. Adapters are no longer included with the appliance or war distribution. Each adapter is a separate download on the Keycloak download site. They are also available as a maven artifact. -You must unzip the Jetty 9.x distro into Jetty 9.x's link:https://www.eclipse.org/jetty/documentation/jetty-9/index.html#startup-base-and-home[base directory]. +You must unzip the Jetty 9.x distro into Jetty 9.x's link:https://www.eclipse.org/jetty/documentation/current/#quickstart-common-config[base directory]. Including adapter's jars within your WEB-INF/lib directory will not work! In the example below, the Jetty base is named `your-base`: diff --git a/server_admin/topics/roles-groups/con-default-roles.adoc b/server_admin/topics/roles-groups/con-default-roles.adoc new file mode 100644 index 0000000000..87a283c245 --- /dev/null +++ b/server_admin/topics/roles-groups/con-default-roles.adoc @@ -0,0 +1,13 @@ +[id="con-default-roles_{context}"] + +[[_default_roles]] +==== Default Roles +[role="_abstract"] +Default roles allow you to automatically assign user role mappings when any user is newly created or imported through +<<_identity_broker, Identity Brokering>>. +To specify default roles go to the *Roles* left menu item, and click the *Default Roles* tab. + +.Default Roles +image:{project_images}/default-roles.png[] + +This screenshot shows that some _default roles_ already exist. diff --git a/server_installation/topics/clustering/sticky-sessions.adoc b/server_installation/topics/clustering/sticky-sessions.adoc index 2c06cad30c..e4a9bc5297 100644 --- a/server_installation/topics/clustering/sticky-sessions.adoc +++ b/server_installation/topics/clustering/sticky-sessions.adoc @@ -19,7 +19,7 @@ The workflow in the cluster environment with the public frontend load balancer a but can be chosen according to some other criterias (client IP address etc). It all depends on the implementation and configuration of underlying load balancer (reverse proxy). * {project_name} creates authentication session with random ID (eg. 123) and saves it to the Infinispan cache. * Infinispan distributed cache assigns the primary owner of the session based on the hash of session ID. -See link:https://infinispan.org/docs/stable/titles/configuring/configuring.html#distribution-configuring[Infinispan documentation] for more details around this. +See link:https://infinispan.org/docs/10.1.x/titles/configuring/configuring.html#clustered_caches[Infinispan documentation] for more details around this. Let's assume that Infinispan assigned `node2` to be the owner of this session. * {project_name} creates the cookie `AUTH_SESSION_ID` with the format like `.` . In our example case, it will be `123.node2` . * Response is returned to the user with the {project_name} login screen and the AUTH_SESSION_ID cookie in the browser diff --git a/server_installation/topics/operating-mode/crossdc.adoc b/server_installation/topics/operating-mode/crossdc.adoc index 0b5f6892e0..de9e653a34 100644 --- a/server_installation/topics/operating-mode/crossdc.adoc +++ b/server_installation/topics/operating-mode/crossdc.adoc @@ -137,10 +137,9 @@ For more detail about how caches can be configured see <>. [[communication]] ==== Communication details -{project_name} uses multiple, separate clusters of Infinispan caches. Every {project_name} node is in the cluster with the other {project_name} nodes in same data center, but not with the {project_name} nodes in different data centers. A {project_name} node does not communicate directly with the {project_name} nodes from different data centers. {project_name} nodes use external {jdgserver_name} servers for communication across data centers. This is done using the link:https://infinispan.org/docs/11.0.x/titles/hotrod_java/hotrod_java.html[Infinispan Hot Rod protocol]. +{project_name} uses multiple, separate clusters of Infinispan caches. Every {project_name} node is in the cluster with the other {project_name} nodes in same data center, but not with the {project_name} nodes in different data centers. A {project_name} node does not communicate directly with the {project_name} nodes from different data centers. {project_name} nodes use external JDG (actually {jdgserver_name} servers) for communication across data centers. This is done using the link:https://infinispan.org/docs/10.1.x/titles/server/server.html#hot_rod[Infinispan HotRod protocol]. -The Infinispan caches on the {project_name} side use link:https://infinispan.org/docs/stable/titles/configuring/configuring.html#remote_cache_store[`remoteStore`] configuration to offload data to a remote {jdgserver_name} cluster. -{jdgserver_name} clusters in separate data centers then replicate that data to ensure it is backed up. +The Infinispan caches on the {project_name} side must be configured with the link:https://infinispan.org/docs/10.1.x/titles/configuring/configuring.html#remote_cache_store[remoteStore] to ensure that data are saved to the remote cache. There is separate Infinispan cluster between JDG servers, so the data saved on JDG1 on `site1` are replicated to JDG2 on `site2` . The receiving {jdgserver_name} server notifies the {project_name} servers in its cluster through Client Listeners, which are a feature of the Hot Rod protocol. {project_name} nodes on `site2` then update their Infinispan caches and the particular user session is also visible on {project_name} nodes on `site2`. diff --git a/tests/src/test/resources/ignored-links b/tests/src/test/resources/ignored-links index f13b8b1c2f..46cb2589ba 100644 --- a/tests/src/test/resources/ignored-links +++ b/tests/src/test/resources/ignored-links @@ -8,6 +8,7 @@ http://localhost:8181* http://127.0.0.1:3000* https://myhost.com/myapp/k_jwks https://myhost.com/myapp +http://host.com/* http://host:port* https://host:port* http://broker-keycloak:8180* diff --git a/upgrading/topics/keycloak/changes.adoc b/upgrading/topics/keycloak/changes.adoc index 94557add41..85ad7eb598 100644 --- a/upgrading/topics/keycloak/changes.adoc +++ b/upgrading/topics/keycloak/changes.adoc @@ -441,7 +441,7 @@ or `resourceAccess` properties, you may need to increase the priority of your ma Audiences of all the clients, for which authenticated user has at least one client role in the token, are automatically added to the `aud` claim in the access token now. On the other hand, an access token may not automatically contain the audience of the -frontend client, for which it was issued. Read the link:{adminguide_link}#_audience[{adminguide_name}] for more details. +frontend client, for which it was issued. Read the link:{adminguide_link}#audience-support[{adminguide_name}] for more details. ==== JavaScript Adapter Promise