integrated latest changes into new files

server_admin/topics/authentication/clients/oidc/con-advanced-settings.adoc

@@ -73,8 +73,7 @@ The client must pass its public key for encrypting CEK to {project_name}. {proje
 
 The procedure is:
 
-. Open the client's *Credentials* tab.
-. Select *Signed Jwt* from the *Client Authenticator* menu.
+. Open the client's *Keys* tab.
 . Toggle *JWKS URL* to ON.
 . Input the client's public key URL in the *JWKS URL* textbox.
 

server_admin/topics/authentication/clients/oidc/con-basic-settings.adoc

@@ -32,6 +32,10 @@ _Bearer-only_::
 
 *Direct Access Grants Enabled*:: When enabled, clients can use the OIDC xref:_oidc-auth-flows-direct[Direct Access Grants].
 
+*OAuth 2.0 Device Authorization Grant Enabled*
+
+If this is on, clients are allowed to use the OIDC <<_oidc-auth-flows,Device Authorization Grant>>.
+
 *Root URL*:: This value adds a prefix to any configured URLS that {project_name} uses.
 
 *Valid Redirect URIs*:: Required field.  Enter a URL pattern and click *+* to add and *-* to remove existing URLs and click *Save*. You can use wildcards at the end of the URL pattern. For example $$http://host.com/*$$

server_admin/topics/authentication/clients/oidc/con-confidential-client-credentials.adoc

@@ -19,7 +19,12 @@ image:{project_images}/client-credentials-jwt.png[]
 
 *Signed JWT* is "Signed Json Web Token".
 
-To use the *Signed JWT* credential type, a private key and certificate must be generated for the client. The private key is used to sign the JWT and the certificate is used by the server to verify the signature. Click *Generate new keys and certificate* to begin this process.
+When choosing this credential type you will have to also generate a private key and certificate for the client in the tab `Keys`. The private key will be used to sign the JWT, while the certificate is used by the server to verify the signature.
+
+.Keys Tab
+image:{project_images}/client-oidc-keys.png[]
+
+Click on the `Generate new keys and certificate` button to start this process.
 
 .Generate Keys
 image:{project_images}/generate-client-keys.png[]
@@ -34,7 +39,7 @@ When you generate the keys, {project_name} will store the certificate and you do
 You can also generate keys using an external tool and then import the client's certificate by clicking *Import Certificate*.
 
 .Import Certificate
-image:{project_images}/import-client-cert.png[]
+image:{project_images}/import-client-cert.png[Import Certificate]
 
 . Select the archive format of the certificate.
 . Enter the store password.

server_admin/topics/authentication/clients/saml/proc-creating-saml-client.adoc

@@ -64,7 +64,7 @@ This option is used when {project_name} server and adapter provide the IDP and S
 
 *Encrypt Assertions*:: Encrypts the assertions in SAML documents with the realms private key. The AES algorithm uses a key size of 128 bits. 
 
-*Client Signature Required*:: If *Client Signature Required* is enabled, documents coming from a client are expected to be signed. {project_name} validates this signature using the client public key or certificate set up in the *SAML Keys* tab.
+*Client Signature Required*:: If *Client Signature Required* is enabled, documents coming from a client are expected to be signed. {project_name} will validate this signature using the client public key or cert set up in the `Keys` tab.
 
 *Force POST Binding*:: By default, {project_name} responds using the initial SAML binding of the original request. By enabling *Force POST Binding*, {project_name} responds using the SAML POST binding even if the original request used the redirect binding.
 

server_admin/topics/realms/keys.adoc

@@ -36,8 +36,14 @@ How long you wait to delete old keys is a tradeoff between security and making s
 In general it should be acceptable to drop old keys after a few weeks. Users that have not been active in the period
 between the new keys where added and the old keys removed will have to re-authenticate.
 
+<<<<<<< HEAD
 This also applies to offline tokens. To make sure they are updated the applications need to refresh the tokens before
 the old keys are removed.
+=======
+The frequency of deleting old keys is a tradeoff between security and making sure all cookies and tokens are updated. Consider creating new keys every three to six months and deleting old keys one to two months after you create the new keys. If a user was inactive in the period between the new keys being added and the old keys being removed, that user will have to re-authenticate.
+
+Rotating keys also applies to offline tokens. To make sure they are updated, the applications need to refresh the tokens before the old keys are removed.
+>>>>>>> integrated latest changes into new files
 
 As a guideline, it may be a good idea to create new keys every 3-6 months and delete old keys 1-2 months after the new
 keys were created.

server_admin/topics/realms/master.adoc

@@ -7,7 +7,7 @@ In the Admin Console, two types of realms exist:
 * `Other realms` - These realms are created by the administrator in the master realm. In these realms, administrators manage the users in your organization and the applications they need. The applications are owned by the users.
 
 .Realms and applications
-image:../../../../getting_started/images/master_realm.png[Realms and applications]
+image:../../../getting_started/images/master_realm.png[Realms and applications]
 
 Realms are isolated from one another and can only manage and authenticate the users that they control. Following this security model helps prevent accidental changes and follows the tradition
 of permitting user accounts access to only those privileges and powers necessary

server_admin/topics/realms/themes.adoc

@@ -64,9 +64,16 @@ The logic for selecting the locale uses the first of the following that is avail
 * Realm default
 * If none of the above, fall back to English
 
+<<<<<<< HEAD
 When a user is authenticated an action is triggered to update the locale in the persisted cookie mentioned earlier. If the
 user has actively switched the locale through the locale selector on the login pages the users locale is also updated at
 this point.
 
 If you want to change the logic for selecting the locale, you have an option to create custom `LocaleSelectorProvider`. For details, please refer to the
 link:{developerguide_link}#_locale_selector[{developerguide_name}].
+=======
+When a user is authenticated, an action is triggered to update the locale in the persisted cookie mentioned earlier. If the user has actively switched the locale through the locale selector on the login pages, the user's locale is also updated at this point.
+
+If you want to change the logic for selecting the locale, you have an option to create a custom `LocaleSelectorProvider`. For details, see the
+link:{developerguide_link}#_locale_selector[{developerguide_name}].
+>>>>>>> integrated latest changes into new files

server_admin/topics/sso-protocols/con-oidc-auth-flows.adoc

@@ -71,3 +71,11 @@ The HTTP response contains the _identity_, _access_, and _refresh_ tokens.
 The _Client Credentials Grant_ creates a token based on the metadata and permissions of a service account associated with the client instead of obtaining a token that works on behalf of an external user. _Client Credentials Grants_ are used by REST clients.
 
 See the <<_service_accounts,Service Accounts>> chapter for more information.
+
+===== Device Authorization Grant
+
+This is used by clients running on internet-connected devices that have limited input capabilities or lack a suitable browser. Here's a brief summary of the protocol:
+
+. The application requests {project_name} a device code and a user code. {project_name} creates a device code and a user code. {project_name} returns a response including the device code and the user code to the application.
+. The application provides the user with the user code and the verification URI. The user accesses a verification URI to be authenticated by using another browser.
+. The application repeatedly polls {project_name} to find out if the user completed the user authorization. If user authentication is complete, the application exchanges the device code for an _identity_, _access_ and _refresh_ token.

server_admin/topics/sso-protocols/con-server-oidc-uri-endpoints.adoc

@@ -23,3 +23,11 @@ https://localhost:8080/auth
 
 /realms/{realm-name}/protocol/openid-connect/revoke::
   Used for OAuth 2.0 Token Revocation described in https://tools.ietf.org/html/rfc7009[RFC7009].
+
+/realms/{realm-name}/protocol/openid-connect/certs::
+  Used for the JSON Web Key Set (JWKS) containing the public keys used to verify any JSON Web Token (jwks_uri)
+  
+/realms/{realm-name}/protocol/openid-connect/auth/device::
+  Used for Device Authorization Grant to obtain a device code and a user code.
+
+In all of these, replace {realm-name} with the name of the realm.

server_admin/topics/user-federation/ldap.adoc

@@ -37,7 +37,7 @@ When you attempt to change the non-LDAP mapped user data, the user update is not
 
 ==== Edit Mode
 
-Users and admins can modify user metadata, users through the <<_account-service, Account Console>>, and admins through the admin console. The `Edit Mode` configuration on the LDAP configuration page defines the user's LDAP update privileges.
+Users and admins can modify user metadata, users through the <<_account-service, Account Console>>, and administrators through the Admin Console. The `Edit Mode` configuration on the LDAP configuration page defines the user's LDAP update privileges.
 
 READONLY::
 You cannot change the username, email, first name, last name, and other mapped attributes. {project_name} shows an error anytime a user attempts to update these fields. Password updates are not supported.
@@ -72,7 +72,7 @@ Hover the mouse pointer over the tooltips in the Admin Console to see more detai
 
 ==== Connecting to LDAP over SSL
 
-When you configure a secure connection URL to your LDAP store (for example,`ldaps://myhost.com:636'), {project_name} uses SSL to communicate with the LDAP server. Configure a truststore on the {project_name} server side so that {project_name} can trust the SSL connection to LDAP.
+When you configure a secure connection URL to your LDAP store (for example,`ldaps://myhost.com:636`), {project_name} uses SSL to communicate with the LDAP server. Configure a truststore on the {project_name} server side so that {project_name} can trust the SSL connection to LDAP.
 
 Configure the global truststore for {project_name} with the Truststore SPI. For more information about configuring the global truststore, see the link:{installguide_link}[{installguide_name}]. If you do not configure the Truststore SPI, the truststore falls back to the default mechanism provided by Java, which can be the file supplied by the `javax.net.ssl.trustStore` system property or the cacerts file from the JDK if the system property is unset.
 
@@ -144,13 +144,24 @@ When {project_name} updates a password, {project_name} sends the password in pla
 
 By default, LDAP servers such as MSAD, RHDS, or FreeIPA hash and salt passwords. Other LDAP servers such as OpenLDAP or ApacheDS store the passwords in plain-text unless you use the _LDAPv3 Password Modify Extended Operation_ as described in https://tools.ietf.org/html/rfc3062[RFC3062]. Enable the LDAPv3 Password Modify Extended Operation in the LDAP configuration page. See the documentation of your LDAP server for more details.
 
+<<<<<<< HEAD
 WARNING: Always verify that user passwords are properly hashed and not stored as plaintext by inspecting a changed
 directory entry using `ldapsearch` and base64 decode the `userPassword` attribute value.
+=======
+[WARNING]
+====
+Always verify that user passwords are properly hashed and not stored as plaintext by inspecting a changed directory entry using `ldapsearch` and base64 decode the `userPassword` attribute value.
+====
+>>>>>>> integrated latest changes into new files
 
 [[_ldap_troubleshooting]]
 ==== Troubleshooting
 
+<<<<<<< HEAD
 - It is useful to increase the logging level to TRACE for the category `org.keycloak.storage.ldap`. You increase this level in the logging
+=======
+It is useful to increase the logging level to TRACE for the category `org.keycloak.storage.ldap`. You increase this level in the logging
+>>>>>>> integrated latest changes into new files
 subsystem in the `standalone(-ha).xml` file. With this setting, many logging messages are sent
 to the `server.log` file in the `TRACE` level, including the logging for all queries to the LDAP server and the parameters, which were
 used to send the queries. When you are creating any LDAP question on user forum or JIRA, consider attaching the server log with
@@ -158,7 +169,11 @@ enabled TRACE logging. If it is too big, the good alternative is to include just
 added to the log during the operation, which causes the issues to you.
 
 
+<<<<<<< HEAD
 - When you create LDAP provider, message appear in the server log in the INFO level starting with:
+=======
+ When you create LDAP provider, message appear in the server log in the INFO level starting with:
+>>>>>>> integrated latest changes into new files
 ```
 Creating new LDAP Store for the LDAP storage provider: ...
 ```
@@ -172,7 +187,11 @@ Mapper for provider: XXX, Mapper name: YYY, Provider: ZZZ ...
 ```
 Note those messages are displayed just with the enabled DEBUG logging.
 
+<<<<<<< HEAD
 - For tracking the performance or connection pooling issues, consider setting the value of property `Connection Pool Debug Level` of
+=======
+For tracking the performance or connection pooling issues, consider setting the value of property `Connection Pool Debug Level` of
+>>>>>>> integrated latest changes into new files
 the LDAP provider to value `all`. This will add lots of additional messages to server log with the included logging for the LDAP connection
 pooling. This can be used to track the issues related to connection pooling or performance.
 
@@ -182,7 +201,14 @@ of the LDAP provider connection.
 If no more messages appear for connection pooling even after server restart, it can indicate that connection pooling does not work
 with your LDAP server.
 
+<<<<<<< HEAD
 - For the case of reporting LDAP issue, you may consider to attach some part of your LDAP tree with the target data, which causes issues
 in your environment. For example if login of some user takes lot of time, you can consider attach his LDAP entry showing count of `member` attributes
 of various "group" entries. In this case, it might be useful to add if those group entries are mapped to some Group LDAP mapper (or Role LDAP Mapper)
 in {project_name} etc.
+=======
+For the case of reporting LDAP issue, you may consider to attach some part of your LDAP tree with the target data, which causes issues
+in your environment. For example if login of some user takes lot of time, you can consider attach his LDAP entry showing count of `member` attributes
+of various "group" entries. In this case, it might be useful to add if those group entries are mapped to some Group LDAP mapper (or Role LDAP Mapper)
+in {project_name} and so on.
+>>>>>>> integrated latest changes into new files

server_development/topics/locale-selector.adoc

@@ -1,10 +1,17 @@
 [[_locale_selector]]
 === Locale Selector
 
+<<<<<<< HEAD
 By default, the locale is selected using the `DefaultLocaleSelectorProvider` which implements the `LocaleSelectorProvider` interface. English is the default language when internationalization is disabled.
 With internationalization enabled, the locale is resolved according to the logic described in the link:{adminguide_link}#_user_locale_selection[{adminguide_name}].
 
 This behaviour can be changed through the `LocaleSelectorSPI` by implementing the `LocaleSelectorProvider` and `LocaleSelectorProviderFactory`.
+=======
+By default, the locale is selected using the `DefaultLocaleSelectorProvider`, which implements the `LocaleSelectorProvider` interface. English is the default language when internationalization is disabled.
+With internationalization enabled, the locale is resolved according to the logic described in the link:{adminguide_link}#_user_locale_selection[{adminguide_name}].
+
+This behavior can be changed through the `LocaleSelectorSPI` by implementing the `LocaleSelectorProvider` and `LocaleSelectorProviderFactory`.
+>>>>>>> integrated latest changes into new files
 
 The `LocaleSelectorProvider` interface has a single method, `resolveLocale`, which must return a locale given a `RealmModel` and a nullable `UserModel`. The actual request is available from the `KeycloakSession#getContext` method.
 

topics/templates/document-attributes-community.adoc

@@ -131,6 +131,10 @@ endif::[]
 :jdgserver_version: 9.4.19
 :jdgserver_version_latest: 11.0.9
 :jdgserver_crossdcdocs_link: https://infinispan.org/docs/11.0.x/titles/xsite/xsite.html
+=======
+:jdgserver_version_latest: 11.0.8
+:jdgserver_crossdcdocs_link: https://access.redhat.com/documentation/en-us/red_hat_data_grid/7.3/html/red_hat_data_grid_user_guide/x_site_replication
+>>>>>>> integrated latest changes into new files
 
 :fuseVersion: JBoss Fuse 6.3.0 Rollup 12
 :fuseHawtioEAPVersion: JBoss EAP 6.4

upgrading/topics/keycloak/changes.adoc

@@ -89,6 +89,25 @@ This can be configured through the admin console on the client details page or t
 to contain the list of Request URI values, which are permitted for the particular client. This is to avoid SSRF attacks. There is possibility to use wildcards
 or relative paths similarly such as the `Valid Redirect URIs` option, however for security purposes, we typically recommend to use as specific value
 as possible.
+=======
+=== Migrating to 13.0.0
+
+==== Upgrade to Wildfly 22
+
+The {project_name} server was upgraded to use Wildfly 22 as the underlying container. This does not directly involve any
+specific {project_name} server functionality, but a few changes related to the migration, which are worth mentioning.
+
+Dependency updates::
+  The dependencies were updated to the versions used by Wildfly 22 server. For example, Infinispan is now `11.0.8.Final`.
+
+Configuration changes::
+  A few configuration changes exist in the `standalone(-ha).xml` and `domain.xml` files. You should follow the <<_install_new_version>>
+  section to handle the migration of configuration files automatically. If more detail is needed, because, for example, you did some
+  configuration changes on your own, the list of the most important changes follows:
+  * The link:https://docs.wildfly.org/22/Admin_Guide.html#MicroProfile_Config_SmallRye[Eclipse MicroProfile Config], link:https://docs.wildfly.org/22/Admin_Guide.html#MicroProfile_Health_SmallRye[Eclipse MicroProfile Health], and link:https://docs.wildfly.org/22/Admin_Guide.html#MicroProfile_Metrics_SmallRye[Eclipse MicroProfile Metrics] subsystems were replaced by link:https://docs.wildfly.org/22/Admin_Guide.html#Health[WildFly subsystem for health] and link:https://docs.wildfly.org/22/Admin_Guide.html#MicroProfile_Metrics_SmallRye[WildFly subsystem for base metrics].
+
+  * The default Wildfly configuration now utilizes the ability to make use of an automatically generated self-signed certificate with Elytron. Refer to link:https://docs.wildfly.org/22/WildFly_Elytron_Security.html#update-wildfly-to-use-the-default-elytron-components-for-application-authentication[a dedicated `applicationSSC` server SSL context section] for details.
+>>>>>>> integrated latest changes into new files
 
 === Migrating to 12.0.0