ahus1 · Oct 16, 2026
@@ -34,4 +34,4 @@ The offline sessions are now lazily fetched from the database by default instead
 === Improved User Search
 
 {project_name} now supports a glob-like syntax for the user search when listing users in the Admin Console,
-which allows for three different types of searches: prefix (`foo*` which became the default search), infix (`\*foo*`), and exact `"foo"`)
+which allows for three different types of searches: prefix (`+foo*+` which became the default search), infix (`+*foo*+`), and exact `"foo"`)
@@ -1,3 +1,3 @@
 = Changes in validating schemes for valid redirect URIs
 
-If an application client is using non http(s) custom schemes, from now on the validation requires that a valid redirect pattern explicitly allows that scheme. Example patterns for allowing `custom` scheme are `custom:/test`, `custom:/test/\*` or `custom:*`. For security reasons a general pattern like `*` does not cover them anymore.
+If an application client is using non http(s) custom schemes, from now on the validation requires that a valid redirect pattern explicitly allows that scheme. Example patterns for allowing `custom` scheme are `custom:/test`, `+custom:/test/*+` or `+custom:*+`. For security reasons a general pattern like `+*+` does not cover them anymore.
@@ -1041,7 +1041,7 @@ $ kcadm.sh get users -r demorealm -q q=username:testuser
 ----
 [NOTE]
 ====
-Filtering does not use exact matching. This example matches the value of the `username` attribute against the `\*testuser*` pattern.
+Filtering does not use exact matching. This example matches the value of the `username` attribute against the `+*testuser*+` pattern.
 ====
 
 For clients, groups, and users you can filter across multiple attributes by specifying a more complex `q` query parameter.  you may use something like -q q="field1:value1 field2:value2". {project_name} returns users that match the condition for all the attributes only.

@@ -20,7 +20,7 @@ method* to restrict only to one specified method of those if you want to authent
 parameters sent in the HTTP POST method body.
 
 WARNING: Viewing the client secret through the Admin REST API requires `manage-clients` permission.
-Users with only `view-clients` permission will see a masked placeholder (`**********`) instead of the actual secret.
+Users with only `view-clients` permission will see a masked placeholder (`+**********+`) instead of the actual secret.
 This applies to the client list endpoint (`GET /admin/realms/{realm}/clients`), the individual client endpoint (`GET /admin/realms/{realm}/clients/{id}`), and the dedicated client secret endpoint (`GET /admin/realms/{realm}/clients/{id}/client-secret`).
 Ensure that any delegated administrator or automation that needs to read client secrets is granted the `manage-clients` realm role.
 
@@ -158,7 +158,7 @@ image:images/x509-client-auth.png[]
 
 The validator also checks the Subject DN of the client certificate and the root Certificate Authority (CA) Subject DN (trust anchor). This way, {project_name} ensures the certificate presented by the client is the expected one and it was issued by the correct CA. As the trust-store or mTLS store is shared among all the realms, this extra security check avoids interferences between CAs.
 
-The certificate Subject DN can use a regexp validation expression instead of the exact DN. If you want to accept all certificates for a specific CA Subject DN, the expression `(.*?)(?:$)` can be used. Nevertheless this configuration is deprecated and will be removed in a future version.
+The certificate Subject DN can use a regexp validation expression instead of the exact DN. If you want to accept all certificates for a specific CA Subject DN, the expression `+(.*?)(?:$)+` can be used. Nevertheless this configuration is deprecated and will be removed in a future version.
 
 Two ways exist for {project_name} to obtain the Client ID from the request:
 

@@ -87,7 +87,7 @@ This option is used when {project_name} server and adapter provide the IDP and S
 *Sign Assertions*:: The assertion is signed and embedded in the SAML XML Auth response.
 
 *Signature Algorithm*:: The algorithm used in signing SAML documents. Note that `SHA1` based algorithms are deprecated and may be removed in a future release.
-We recommend the use of some more secure algorithm instead of `*_SHA1`. Also, with `*_SHA1` algorithms, verifying signatures
+We recommend the use of some more secure algorithm instead of `+*_SHA1+`. Also, with `+*_SHA1+` algorithms, verifying signatures
 do not work if the SAML client runs on Java 17 or higher.
 
 *SAML Signature Key Name*:: Signed SAML documents sent using POST binding contain the identification of the signing key in the *KeyName* element. This action can be controlled by the *SAML Signature Key Name* option. This option controls the contents of the *Keyname*.

@@ -66,7 +66,7 @@ image:images/saml-add-identity-provider.png[Add Identity Provider]
 
 |Signature Algorithm
 |If *Want AuthnRequests Signed* is *ON*, the signature algorithm to use. Note that `SHA1` based algorithms are deprecated and may be removed in a future release.
-We recommend to use some more secure algorithm instead of `*_SHA1`. Also, with `*_SHA1` algorithms, verifying signatures
+We recommend to use some more secure algorithm instead of `+*_SHA1+`. Also, with `+*_SHA1+` algorithms, verifying signatures
 do not work if the SAML identity provider (for example another instance of {project_name}) runs on Java 17 or higher.
 
 |Encryption Algorithm

@@ -31,8 +31,8 @@ Exact::
 Matches only the specified value. `example.com` matches `user@example.com` but not `user@sub.example.com`.
 
 Wildcard::
-Prefix the base domain with `*.` to match the base domain and all its subdomains at any depth.
-`*.example.com` matches `user@example.com`, `user@sub.example.com`, and `user@deep.sub.example.com`.
+Prefix the base domain with `+*.+` to match the base domain and all its subdomains at any depth.
+`+*.example.com+` matches `user@example.com`, `user@sub.example.com`, and `user@deep.sub.example.com`.
 
 == Mapping email addresses to organizations
 
@@ -41,8 +41,8 @@ organization using the following rules:
 
 . Matching is case-insensitive.
 . The most specific match wins, measured by the number of domain parts. For example, when resolving `user@deep.sub.example.com`:
-  * `deep.sub.example.com` (4 parts, exact) wins over `*.sub.example.com` (4 parts, wildcard) and `*.example.com` (3 parts, wildcard).
-  * `*.sub.example.com` (4 parts) wins over `*.example.com` (3 parts).
+  * `deep.sub.example.com` (4 parts, exact) wins over `+*.sub.example.com+` (4 parts, wildcard) and `+*.example.com+` (3 parts, wildcard).
+  * `+*.sub.example.com+` (4 parts) wins over `+*.example.com+` (3 parts).
 . When two domains have the same number of parts, an exact match wins over a wildcard.
 
 The same rules determine which domain is reported in token claims such as the `domain` claim from the
@@ -98,9 +98,9 @@ For the full membership algorithm, see <<authenticating-members_{context},Authen
 
 * A domain cannot be shared across organizations in the same realm.
 * Domains are stored and compared in lowercase.
-* Wildcard domains must have at least 2 parts after the `*.` prefix (e.g. `*.example.com`). Wildcards over bare TLDs such as `*.com` or `*.org` are rejected.
+* Wildcard domains must have at least 2 parts after the `+*.+` prefix (e.g. `+*.example.com+`). Wildcards over bare TLDs such as `+*.com+` or `+*.org+` are rejected.
 * A domain cannot have more than 10 parts.
-* The `*.` wildcard prefix may appear only once and only at the start of the value (e.g. `sub.*.example.com` is rejected).
+* The `+*.+` wildcard prefix may appear only once and only at the start of the value (e.g. `+sub.*.example.com+` is rejected).
 
 == Considerations
 
@@ -109,12 +109,12 @@ Use an exact domain for a single, well-known address. Use a wildcard when new su
 all map to the same organization.
 
 Overlapping domains across organizations are allowed but resolved deterministically::
-An organization may own `*.example.com` while another owns `sub.example.com`. Only one organization is returned per lookup,
+An organization may own `+*.example.com+` while another owns `sub.example.com`. Only one organization is returned per lookup,
 always the most specific match, with exact winning over wildcard at equal specificity. Verify the intended mapping
 before relying on overlapping configurations.
 
 Use exact domains to model exceptions::
-An organization can hold both `*.example.com` and `vip.example.com`. Addresses under `vip.example.com` resolve to the
+An organization can hold both `+*.example.com+` and `vip.example.com`. Addresses under `vip.example.com` resolve to the
 exact entry; all other subdomains fall back to the wildcard.
 
 Domains without routing::

@@ -164,7 +164,7 @@ Notice:
 - Groups appear within the organization claim, not as a separate top-level claim
 - Group paths are relative to the organization
 - Make sure you have a single `organization-membership` mapper so that groups are included in the same claim as the organization data
-- Multiple organizations can be included if the user is a member of multiple organizations and uses `scope=organization:*` or multiple specific scopes like `scope=organization:org-a organization:org-b`
+- Multiple organizations can be included if the user is a member of multiple organizations and uses `+scope=organization:*+` or multiple specific scopes like `scope=organization:org-a organization:org-b`
 
 [[oidc-token-with-roles]]
 ==== Token structure with roles

@@ -41,9 +41,9 @@ Otherwise, if a member of multiple organizations, the user will be prompted to s
 | `organization:<alias>` | Maps to a specific organization with the given alias.
 Multiple organizations can be requested by specifying multiple scopes, for example `organization:org-a organization:org-b`.
 If any of the aliases does not match an existing organization or the user is not a member, the request will be rejected.
-| `organization:*` | Maps to all organizations the user is a member of.
+| `+organization:*+` | Maps to all organizations the user is a member of.
 |===
 
-NOTE: Mixing different scope formats (for example, `organization` with `organization:org-a`, or `organization:org-a` with `organization:*`) is not allowed and will result in an error.
+NOTE: Mixing different scope formats (for example, `organization` with `organization:org-a`, or `organization:org-a` with `+organization:*+`) is not allowed and will result in an error.
 
 For details on including organization groups in tokens, see <<_managing_groups_,Managing groups>>.
@@ -5,6 +5,6 @@ An open redirector is an endpoint using a parameter to automatically redirect a
 
 {project_name} requires that all registered applications and clients register at least one redirection URI pattern. When a client requests that {project_name} performs a redirect, {project_name} checks the redirect URI against the list of valid registered URI patterns. Clients and applications must register as specific a URI pattern as possible to mitigate open redirector attacks.
 
-If an application requires a non http(s) custom scheme, it should be an explicit part of the validation pattern (for example `custom:/app/\*`). For security reasons a general pattern like `*` does not cover non http(s) schemes.
+If an application requires a non http(s) custom scheme, it should be an explicit part of the validation pattern (for example `+custom:/app/*+`). For security reasons a general pattern like `+*+` does not cover non http(s) schemes.
 
-By using <<_client_policies, Client Policies>>, an administrator can make sure that clients cannot register open redirect URLs such as `*`.
+By using <<_client_policies, Client Policies>>, an administrator can make sure that clients cannot register open redirect URLs such as `+*+`.
@@ -25,7 +25,7 @@ at the server level.
 
 This is the list of the read-only attributes, which are used internally by the {project_name} default providers and functionalities and hence are always read-only:
 
-* For users: `KERBEROS_PRINCIPAL`, `LDAP_ID`, `LDAP_ENTRY_DN`, `CREATED_TIMESTAMP`, `createTimestamp`, `modifyTimestamp`, `userCertificate`, `saml.persistent.name.id.for.*`, `ENABLED`, `EMAIL_VERIFIED`
+* For users: `KERBEROS_PRINCIPAL`, `LDAP_ID`, `LDAP_ENTRY_DN`, `CREATED_TIMESTAMP`, `createTimestamp`, `modifyTimestamp`, `userCertificate`, `+saml.persistent.name.id.for.*+`, `ENABLED`, `EMAIL_VERIFIED`
 * For administrators: `KERBEROS_PRINCIPAL`, `LDAP_ID`, `LDAP_ENTRY_DN`, `CREATED_TIMESTAMP`, `createTimestamp`, `modifyTimestamp`
 
 System administrators have a way to add additional attributes to this list. The configuration is currently available at the server level.
@@ -38,7 +38,7 @@ kc.[sh|bat] start --spi-user-profile--declarative-user-profile--read-only-attrib
 ----
 
 For this example, users and administrators would not be able to update attribute `foo`. Users would not be able to edit any attributes starting with the `bar`.
-So for example `bar` or `barrier`. Configuration is case-insensitive, so attributes like `FOO` or `BarRier` will be denied as well for this example. The wildcard character `\*` is supported
-only at the end of the attribute name, so the administrator can effectively deny all the attributes starting with the specified character. The `*` in the middle of the attribute is considered
+So for example `bar` or `barrier`. Configuration is case-insensitive, so attributes like `FOO` or `BarRier` will be denied as well for this example. The wildcard character `+*+` is supported
+only at the end of the attribute name, so the administrator can effectively deny all the attributes starting with the specified character. The `+*+` in the middle of the attribute is considered
 as a normal character.
 
@@ -37,14 +37,14 @@ To effectively prevent SSRF, Regular Expressions should be designed to exclude I
 
 This pattern ensures that the {project_name} server only communicates with official domains, preventing the use of `localhost` or numerical IP addresses.
 
-* **Pattern:** `^https://([a-zA-Z0-9-]+\.)?mycompany\.com(/.*)?$`
+* **Pattern:** `+^https://([a-zA-Z0-9-]+\.)?mycompany\.com(/.*)?$+`
 * **Effect:** Blocks attempts to use loopback addresses (e.g., `http://localhost:8080`) or cloud metadata endpoints.
 
 **2. Enforcing HTTPS**
 
 SSRF often exploits unencrypted protocols to bypass internal security controls. Enforcing HTTPS via patterns reduces the attack surface.
 
-* **Pattern:** `^https://[a-zA-Z0-9.-]+(/.*)?$`
+* **Pattern:** `+^https://[a-zA-Z0-9.-]+(/.*)?$+`
 * **Result:** Rejects the use of the `http://` scheme, which is frequently used to probe internal services.
 
 NOTE: https can be enforced also with the *Secure Client Uris* executor but only together with wildcards and for all the client URIs
@@ -53,7 +53,7 @@ NOTE: https can be enforced also with the *Secure Client Uris* executor but only
 
 If your clients use JWKS URI from third-party providers, only add the specific domains belonging to those providers.
 
-* **Pattern:** `^https://trusted-provider\.io/.*`
+* **Pattern:** `+^https://trusted-provider\.io/.*+`
 * **Result:** All other domains will be rejected for JWKS requests.
 
 

@@ -19,8 +19,8 @@ Search for a user to view detailed information about the user, such as the user'
 The criteria used to match users depends on the syntax used on the search box:
 +
 .. `"somevalue"` -> performs exact search of the string `"somevalue"`;
-.. `\*somevalue*` -> performs infix search, akin to a `LIKE '%somevalue%'` DB query;
-.. `somevalue*` or `somevalue` -> performs prefix search, akin to a `LIKE 'somevalue%'` DB query.
+.. `+*somevalue*+` -> performs infix search, akin to a `LIKE '%somevalue%'` DB query;
+.. `+somevalue*+` or `somevalue` -> performs prefix search, akin to a `LIKE 'somevalue%'` DB query.
 
 == Search by fields
 

@@ -21,8 +21,8 @@ Before upgrading it is recommended to review all metrics returned from the endpo
 |`base_thread_count`
 |`jvm_threads_live_threads`
 
-|`vendor_agroal_*`
-|`agroal_*`
+|`+vendor_agroal_*+`
+|`+agroal_*+`
 
 |===
-Original file line number
+Diff line change
@@ Expand Up / @@ -1041,7 +1041,7 @@ $ kcadm.sh get users -r demorealm -q q=username:testuser @@
     ----
     [NOTE]
     ====
-    Filtering does not use exact matching. This example matches the value of the `username` attribute against the `\*testuser*` pattern.
+    Filtering does not use exact matching. This example matches the value of the `username` attribute against the `+*testuser*+` pattern.
     ====
     For clients, groups, and users you can filter across multiple attributes by specifying a more complex `q` query parameter.  you may use something like -q q="field1:value1 field2:value2". {project_name} returns users that match the condition for all the attributes only.
@@ Expand Down @@