libre.sh/keycloak-scim
4
0
Fork 0
Code Issues 15 Pull requests Releases 1 Activity Actions

[KEYCLOAK-16788] Fix broken links

Browse source
This commit is contained in:
Stefan Guilhen 2021-01-12 15:03:33 -03:00 committed by Hynek Mlnařík
parent f51560fb90
commit 9a21c9cb05
6 changed files with 11 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
.github/workflows/maven.yml vendored
View file

@ -20,7 +20,7 @@ jobs:
with:
java-version: 1.8
- name: Build with Maven
run: mvn package
run: mvn package -B
build-product:
name: Build and test Product documentation
runs-on: ubuntu-latest
@ -31,4 +31,4 @@ jobs:
with:
java-version: 1.8
- name: Build with Maven
run: mvn package -Dproduct
run: mvn package -B -Dproduct

4
release_notes/topics/product/7_4_final.adoc
View file

@ -158,11 +158,11 @@ Two features have a change in status:
= Fixed Issues
More than 1100 issues were fixed during this release. For details on the fixed issues, see link:https://issues.redhat.com/issues/?filter=12346377[https://issues.redhat.com/issues/?filter=12346377].
More than 1100 issues were fixed during this release. For details on the fixed issues, see link:https://issues.redhat.com/browse/KEYCLOAK-13785?filter=12346377[https://issues.redhat.com/issues/?filter=12346377].
= Known issues
This release includes the following link:https://issues.redhat.com/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20issuetype%20%3D%20Bug%20AND%20fixVersion%20%3D%209.0.4%20AND%20component%20not%20in%20(Infra%2C%20Testsuite%2C%20%22Testsuite%20-%20Performance%22)[known issues] and in particular these higher level issues.
This release includes the following known issues:
* link:https://issues.redhat.com/browse/KEYCLOAK-13589[KEYCLOAK-13589] - Can't add user in admin console when 'Email as username' is enabled

2
securing_apps/topics/oidc/java/jetty9-adapter.adoc
View file

@ -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/current/startup-base-and-home.html[base directory].
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].
Including adapter's jars within your WEB-INF/lib directory will not work!
In the example below, the Jetty base is named `your-base`:

6
server_admin/topics/authentication/webauthn.adoc
View file

@ -2,7 +2,7 @@
=== W3C Web Authentication (WebAuthn)
{project_name} provides the limited support for https://www.w3.org/TR/webauthn/[W3C Web Authentication (WebAuthn)]. {project_name} works as a WebAuthn's https://www.w3.org/TR/webauthn/#rp-operations[Relying Party (RP)].
{project_name} provides the limited support for https://www.w3.org/TR/webauthn/[W3C Web Authentication (WebAuthn)]. {project_name} works as a WebAuthn's https://www.w3.org/TR/webauthn/#sctn-rp-operations[Relying Party (RP)].
ifeval::[{project_product}==true]
:tech_feature_name: WebAuthn
@ -122,14 +122,14 @@ The configurable items and their description follow.
|Attestation Conveyance Preference
|It tells the WebAuthn API implementation on the browser (https://www.w3.org/TR/webauthn/#webauthn-client[WebAuthn Client]) the preference of how to generate an Attestation Statement. This is an optional configuration item that is applied to the operation of registering a WebAuthn authenticator. If no option is selected, its behavior is the same as selecting "none".
For more details, see https://www.w3.org/TR/webauthn/#attestation-convey[WebAuthn Specification].
For more details, see https://www.w3.org/TR/webauthn/#attestation-conveyance[WebAuthn Specification].
|Authenticator Attachment
|It tells the WebAuthn Client an acceptable attachment pattern of a WebAuthn authenticator. This is an optional configuration item that is applied to the operation of registering a WebAuthn authenticator. If no option is selected, the WebAuthn Client does not consider the attachment pattern.
For more details, see https://www.w3.org/TR/webauthn/#enumdef-authenticatorattachment[WebAuthn Specification].
|Require Resident Key
|It tells the WebAuthn authenticator to generate the Public Key Credential as https://www.w3.org/TR/webauthn/#client-side-resident-public-key-credential-source[Client-side-resident Public Key Credential Source]. This is an optional configuration item that is applied to the operation of registering a WebAuthn authenticator. If no option is selected, its behavior is the same as selecting "No".
|It tells the WebAuthn authenticator to generate the Public Key Credential as https://www.w3.org/TR/webauthn/#client-side-discoverable-public-key-credential-source[Client-side-resident Public Key Credential Source]. This is an optional configuration item that is applied to the operation of registering a WebAuthn authenticator. If no option is selected, its behavior is the same as selecting "No".
For more details, see https://www.w3.org/TR/webauthn/#dom-authenticatorselectioncriteria-requireresidentkey[WebAuthn Specification].
|User Verification Requirement

2
server_installation/topics/clustering/sticky-sessions.adoc
View file

@ -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/8.2.x/user_guide/user_guide.html#distribution_mode[Infinispan documentation] for more details around this.
See link:https://infinispan.org/docs/stable/titles/configuring/configuring.html#distribution-configuring[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 `<session-id>.<owner-node-id>` . 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

4
server_installation/topics/operating-mode/crossdc.adoc
View file

@ -132,9 +132,9 @@ For more detail about how caches can be configured see <<tuningcache>>.
[[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 JDG (actually {jdgserver_name} servers) for communication across data centers. This is done using the link:https://infinispan.org/docs/8.2.x/user_guide/user_guide.html#using_hot_rod_server[Infinispan HotRod 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/stable/titles/hotrod_java/hotrod_java.html[Infinispan HotRod protocol].
The Infinispan caches on the {project_name} side must be configured with the link:https://infinispan.org/docs/8.2.x/user_guide/user_guide.html#remote_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 Infinispan caches on the {project_name} side must be configured with the link:https://infinispan.org/docs/stable/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` .
Finally, the receiving JDG server notifies the {project_name} servers in its cluster through the Client Listeners, which are a feature of the HotRod 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`.