Resolved conflicts

server_admin/topics/identity-broker/first-login-flow.adoc

@@ -26,7 +26,6 @@ Review Profile::
 * When *OFF*, the profile page does not display unless the user clicks in a later phase on the `Review profile info` link in the page displayed by the `Confirm Link Existing Account` authenticator.
 
 Create User If Unique::
-<<<<<<< HEAD
   This authenticator checks if there is already an existing {project_name} account with the same email or username like the account from the identity provider.
   If it's not, then the authenticator just creates a new local {project_name} account and links it with the identity provider and the whole flow is finished.
   Otherwise it goes to the next `Handle Existing Account` subflow.
@@ -34,16 +33,15 @@ Create User If Unique::
   will see the error page if there is an existing {project_name} account and the user will need to link the identity provider account through Account management.
 =======
 * This authenticator verifies that there is already a {project_name} account with the same email or username as the identity provider's account.
-* If an account does not exist, the authenticator creates a local {project_name} account, links this account with the identity provider, and terminates the flow. 
+* If an account does not exist, the authenticator creates a local {project_name} account, links this account with the identity provider, and terminates the flow.
 * If an account exists, the authenticator implements the next `Handle Existing Account` sub-flow.
 * To ensure there is no duplicated account, you can mark this authenticator as `REQUIRED`. The user sees the error page if a {project_name} account exists, and users must link their identity provider account through Account management.
->>>>>>> KEYCLOAK-15756 Initial wording (#58)
 
 NOTE: If you want to skip the ability to create new users, but you want that users authenticated from identity provider must already exists in {project_name} with same username or email like the user from identity provider, you can create new flow and replace `Create User If Exists` authenticator with `Detect Existing Broker User` . More details in the <<Detect Existing User First Login Flow,examples below>>.
-  
+
 Confirm Link Existing Account::
 * On the information page, users see a {project_name} account with the same email. Users can review their profile again and use a different email or username. The flow restarts and goes back to the `Review Profile` authenticator.
-* Alternatively, users can confirm that they want to link their identity provider account with their existing {project_name} account. 
+* Alternatively, users can confirm that they want to link their identity provider account with their existing {project_name} account.
 * Disable this authenticator if you do not want users to see this confirmation page and go straight to linking identity provider account by email verification or re-authentication.
 
 Verify Existing Account By Email::
@@ -91,7 +89,6 @@ To disable user creation:
 . Set *Create User If Unique* to *DISABLED*.
 . Set *Confirm Link Existing Account* to *DISABLED*.
 
-<<<<<<< HEAD
 This configuration also implies that Keycloak itself won't be able to determine which internal account would correspond to the external identity.
 Therefore, the `Verify Existing Account By Re-authentication` authenticator will ask the user to provide both username and password.
 
@@ -115,4 +112,3 @@ You could set the also set `Sync Mode` to `force` if you want to update the user
 NOTE: This flow can be used if you want to delegate the identity to other identity providers (such as github, facebook ...) but you want to manage which users that can log in.
 =======
 With this configuration, {project_name} is unable to determine which internal account corresponds to the external identity. The *Verify Existing Account By Re-authentication* authenticator asks the provider for the username and password.
->>>>>>> KEYCLOAK-15756 Initial wording (#58)

server_admin/topics/identity-broker/saml.adoc

@@ -31,6 +31,8 @@ image:{project_images}/saml-add-identity-provider.png[Add Identity Provider]
 |The URI reference corresponding to a name identifier format. By default, {project_name} sets it to `urn:oasis:names:tc:SAML:2.0:nameid-format:persistent`.
 
 |Principal Type
+|Specifies which part of the SAML assertion will be used to identify and track external user identities. Can be either Subject NameID or SAML attribute (either by name or by friendly name). Subject NameID value can not be set together with 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient' NameID Policy Format value.
+=======
 |Specifies the part of the SAML assertion {project_name} uses to identify and track external user identities. The Principal Type can be Subject NameID or SAML attribute (by name or by friendly name).
 
 |Principal Attribute
@@ -70,17 +72,7 @@ image:{project_images}/saml-add-identity-provider.png[Add Identity Provider]
 |When *ON*, {project_name} uses the realm's key pair to sign the <<_identity_broker_saml_sp_descriptor, SAML Service Provider Metadata descriptor>>.
 
 |Pass subject
-<<<<<<< HEAD
-|Whether or not a `login_hint` query parameter should be forwarded to the IDP. When provided, this login_hint parameter is added to AuthnRequest's Subject. This allows destination providers to prefill their login form. When no login_hint is provided, nothing is forwarded as an AuthnRequest Subject.
-
-|Attribute Consuming Service Index
-|Identifies the attribute set to request to the remote IDP. {project_name} automatically adds the attributes mapped in the identity provider configuration to the autogenerated SP metadata document.
-
-|Attribute Consuming Service Name
-|A descriptive name for the set of attributes that are advertised in the autogenerated SP metadata document.
-=======
 |Controls if {project_name} forwards a `login_hint` query parameter to the IDP. {project_name} adds this field's value to the login_hint parameter in the AuthnRequest's Subject so destination providers can pre-fill their login form.
->>>>>>> 6f455950... KEYCLOAK-15756 Initial wording (#58)
 |===
 
 You can import all configuration data by providing a URL or a file pointing to the SAML IDP entity descriptor of the external IDP. If you are connecting to a {project_name} external IDP, you can import the IDP settings from the URL `<root>/auth/realms/{realm-name}/protocol/saml/descriptor`. This link is an XML document describing metadata about the IDP. You can also import all this configuration data by providing a URL or XML file pointing to the external SAML IDP's entity descriptor to connect to.

server_admin/topics/overview.adoc

@@ -1,12 +1,4 @@
-<<<<<<< HEAD
-<<<<<<< HEAD
 == {project_name} features and concepts
-=======
-== Features and Concepts for {project_name}
->>>>>>> Rework server initialization chapter
-=======
-== {project_name} features and concepts
->>>>>>> Reworked chapter 1, the overview chapter
 
 {project_name} is a single sign on solution for web apps and RESTful web services.  The goal of {project_name}
 is to make security simple so that it is easy for application developers to secure the apps and services they have deployed

server_admin/topics/realms/keys.adoc

@@ -36,14 +36,12 @@ 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/themes.adoc

@@ -64,16 +64,13 @@ 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/user-federation/ldap.adoc

@@ -144,24 +144,15 @@ 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
@@ -169,11 +160,10 @@ 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: ...
 ```
@@ -187,11 +177,9 @@ 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.
 
@@ -201,14 +189,13 @@ 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,17 +1,15 @@
 [[_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`.
-=======
+This behavior 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,10 +131,9 @@ 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,7 +89,7 @@ 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
@@ -107,7 +107,7 @@ Configuration changes::
   * 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