Merge branch 'development' into kv-oidc-anonymous-user

Author: Karuna-Mendix

content/en/docs/deployment/mendix-cloud-deploy/backups/restore-backup-locally.md

@@ -22,7 +22,7 @@ This how-to explains how to do the following:
 Before starting this how-to, make sure you have completed the following prerequisites:
 
 * [Download a backup](/developerportal/operate/download-backup/) that you want to restore locally.
-* Install PostgreSQL version 12 or above (as you need pgAdmin version 4.12 or above) on your local machine by downloading and running the [PostgreSQL Installer](https://www.postgresql.org/download/windows/). When installing, use the program defaults and choose a password.
+* Install PostgreSQL version 17 or above (you need pgAdmin version [8.14](https://www.postgresql.org/ftp/pgadmin/pgadmin4/v8.14/) or above) on your local machine by downloading and running the [PostgreSQL Installer](https://www.postgresql.org/download/windows/). When installing, use the program defaults and choose a password.
 
     {{% alert color="info" %}}You will need this password later to allow your Mendix app to access the restored data.{{% /alert %}}
 

content/en/docs/deployment/mendix-cloud-deploy/backups/restore-backup.md

@@ -162,7 +162,7 @@ This folder contains the *db.backup* file, which is a PostgreSQL dump file creat
 {{% alert color="warning" %}}
 If the dump does not use the custom format, then the restore will fail.
 
-The dump must be created with `pg_dump` version 1.15 or below, which is currently bundled with PostgreSQL 13, 14, and 15. If it is created with a later version, then the upload will fail.
+The dump must be created with `pg_dump` version 1.16 or below, which is currently bundled with PostgreSQL 17 and below. If it is created with a version above 1.16, the upload will fail.
 
 You can find the exact version of PostgreSQL each environment of your application is using on the [General](/developerportal/deploy/environments-details/#general-tab) tab of each environment's  **Environment Details** page.
 {{% /alert %}}

content/en/docs/howto/data-models/migrating-your-mendix-database.md

@@ -110,7 +110,7 @@ If you are using [pg_dump](https://www.postgresql.org/docs/current/app-pgdump.ht
 For more information about pg_dump methods, see [SQL Dump](https://www.postgresql.org/docs/current/backup-dump.html).
 
 {{% alert color="warning" %}}
-As described in [Restoring a Backup](/developerportal/operate/restore-backup/#db-folder), the backup must be created using pg_dump version 1.14 or below, which is currently bundled with PostgreSQL 12, 13, 14, and 15. If it is created with a later version, then it will not be possible to upload the file to Mendix Cloud.
+As described in [Restoring a Backup](/developerportal/operate/restore-backup/#db-folder), the backup must be created using pg_dump version 1.16 or below, which is currently bundled with PostgreSQL 17 and below. If it is created with a version above 1.16, it will not be possible to upload the file to Mendix Cloud.
 {{% /alert %}}
 
 #### Using pgAdmin

content/en/docs/marketplace/platform-supported-content/modules/oidc.md

@@ -56,7 +56,7 @@ The OIDC SSO module supports the following features:
     * Supports SSO and API-security.
     * Can be used with OIDC/OAuth-compatible IdPs, such as AWS Cognito, Google, Salesforce, Apple, Okta, Ping, Microsoft's Entra ID (formerly known as Azure AD), and SAP Cloud Identity Services. Moreover, the module also works with the [OIDC Provider](https://marketplace.mendix.com/link/component/244687) module.
     * Comes with helper microflows (DELETE, GET, PATCH, POST, and PUT) which call an API with a valid token (and automate the token refresh process).
-    * Easy configuration, by leveraging the so-called well-known discovery endpoint at your IdP. PKCE will be used automatically if the IdP supports it.
+    * PKCE is enabled by default for all the IdPs. You can disable it if required. 
     * Configuration can be controlled through constants set during your deployment (version 2.3.0 and above).
     * Supports multiple OIDC IdPs by allowing configuration of user provisioning and access token parsing microflows per IdP.
     * Supports Authentication Context Class Reference (ACR) to allow your app to suggest the desired method or level of authentication for user login to the Identity Provider (IdP) (version 2.3.0 and above).
@@ -70,7 +70,6 @@ The OIDC SSO module supports the following features:
 2. Configuration Experience Features:
 
     * Easy configuration, by leveraging the so-called well-known discovery endpoint at your IdP. The IdP's well-known endpoint also indicates which user claims the IdP may provide during single sign-on. The module reads this information, so the developer does not need to configure it. The available claims can be used in custom provisioning microflow, as described in the section [Custom User Provisioning Using a Microflow.](#custom-provisioning-mf)
-        * For example, PKCE will be used automatically if it is detected.
     * Configuration can be controlled through constants set during your deployment (version 2.3.0 and above).
     * Comes with default user provisioning microflow that works with Entra ID; there you may need to build a custom user provisioning flow.
     * User provisioning microflows can be used from any other modules in your app. They do not need to be exclusively a part of the OIDC module.
@@ -86,7 +85,7 @@ For readers with more knowledge of the OAuth and OIDC protocol:
 * Helps you build an OAuth client that initiates the Authorization Code grant flow to sign the end-user in via the browser.
 * Uses the `nonce` parameter to defend against replay attacks.
 * Validates ID-token signatures.
-* Uses the Proof Key for Code Exchange (PKCE – pronounced “pixie") security enhancement as per RFC 7636. If your IdP’s well-known endpoint indicates *S256* as value for `code_challenge_methods_supported`, the OIDC Module will automatically apply the PKCE feature. PKCE can be seen as a security add-on to the original OAuth protocol. It is generally recommended to use this feature to be better protected against hackers who try to get access to your app. Customers using EntraID may need to update their well-known endpoint, as EntraID does not automatically publish the `code_challenge_methods_supported` parameter. As a result, PKCE will not be enabled automatically.
+* Uses the Proof Key for Code Exchange (PKCE – pronounced “pixie") security enhancement as per RFC 7636. PKCE can be seen as a security add-on to the original OAuth protocol. It is generally recommended to use this feature for better protection against hackers who try to get access to your app. PKCE is enabled by default.
 * When authenticating APIs, it validates access tokens in one of two ways:
 
     * If the IdP supports token introspection, exposing the `/introspect` endpoint of the IdP, the OIDC module will introspect the access token to see if it is valid.
@@ -119,7 +118,6 @@ The OIDC SSO module also has the following limitations:
 * If you use both the [SAML](/appstore/modules/saml/) module and the OIDC SSO module in the same app, each end-user can only authenticate using one IdP.
 * If OIDC SSO is used for API security, it does not validate the value of the `aud` claim, as suggested by [RFC 9068](https://datatracker.ietf.org/doc/html/rfc9068#section-4). Customers should prevent cross-JWT confusion by using unique scope values.
 * The Admin screens have separate tabs for configuring clients that use the Client Credential grant for API security and for situations where your app is used for both SSO and API security. If the first version of your app uses only OIDC SSO for API security and you want to introduce SSO in a later version, the IdP configuration needs to be re-entered on the other tab.
-* Customers using EntraID may need to update their well-known endpoint, as EntraID does not automatically publish the `code_challenge_methods_supported` parameter. As a result, PKCE will not be enabled automatically.
 
 ## Dependencies
 
@@ -205,6 +203,7 @@ This section provides an overview of updates for the OIDC SSO module across diff
 | Mendix Version | OIDC SSO Module Version | Important Migration Changes | Additional Information |
 | --- | --- | --- | --- |
 | 10.24.0 and above | 4.5.0 | - | `Anonymous` module role has beed removed. |
+| | | | Supporting multi-domain using constant. See [Configuring Multi-Domain](#multi-domain) for more information. |
 | 10.24.0 and above | 4.4.0 | Move the `Encryption.Encryptionkey` value to the `OIDC.Encryptionkey` constant. | Dependencies on the Encryption and Nanoflow Commons modules have been removed. <br> **Issued Tokens** tab has been removed from the OIDC Client Configuration page. |
 | 10.24.0 and above | 4.3.0 | - | Supporting multi-domain and sub-path. |
 | 10.24.0 and above | 4.2.1 | In version 4.2.1, automatic migration of the UserCommons has been removed. | Since migration steps were removed in 4.2.1, you must upgrade to OIDC SSO version 4.2.0 first to prevent data loss. This applies to the UserCommons, if you are migrating from any version below 3.0.0, always upgrade to 4.2.0 first, then move to the latest v4.2.1. |
@@ -324,7 +323,9 @@ In this case, the OIDC client is the app you are making.
 
    **Client assertion** is automatically set to *Client ID and Secret*.
 
-4. Choose the **Client authentication method** — make sure that you select a method that is supported by your IdP. You can normally check this via the `token_endpoint_auth_methods_supported` setting on the IdP’s well-known endpoint. Also, ensure that the correct client authentication method is configured at the IdP when you register the client.
+4. PKCE is enabled by default. To disable it, select **No**.
+
+5. Choose the **Client authentication method** — make sure that you select a method that is supported by your IdP. You can normally check this via the `token_endpoint_auth_methods_supported` setting on the IdP’s well-known endpoint. Also, ensure that the correct client authentication method is configured at the IdP when you register the client.
 
     The options are:
     * `client_secret_basic`: Your app will use the HTTP Basic Authentication scheme to authenticate itself at your IdP. This is the default. The `client_secret_basic` makes use of the `client-id` and `client-secret`.
@@ -344,21 +345,21 @@ In this case, the OIDC client is the app you are making.
 
     {{% alert color="info" %}}After a key renewal, some SSO requests may fail if your IdP does not immediately refresh its key cache. {{% /alert %}}
 
-5. Add the **Client Secret** if you choose `client_secret_basic` or `client_secret_post` as client authentication method.
-6. If you have the **Automatic Configuration URL** (also known as the *well-known endpoint*), enter it and click **Import Configuration** to automatically fill the other endpoints.
+6. Add the **Client Secret** if you choose `client_secret_basic` or `client_secret_post` as client authentication method.
+7. If you have the **Automatic Configuration URL** (also known as the *well-known endpoint*), enter it and click **Import Configuration** to automatically fill the other endpoints.
 
     {{% alert color="info" %}} If the endpoint URL does not already end with `/.well-known/openid-configuration`, include it at the end. According to the specifications, the URL you need to enter typically ends with `/.well-known/openid-configuration`. {{% /alert %}}
 
     * If you do not have an automatic configuration URL, you can fill in the other endpoints manually.
-7. Click **Save**
+8. Click **Save**
 
     {{% alert color="info" %}} Your client configuration is not yet complete, but you have to save at this point to allow you to set up the rest of the information. {{% /alert %}}
 
-8. Select your client configuration and click **Edit**.
-9. Select the scopes expected by your OIDC IdP. The standard scopes are `openid`, `profile`, and `email`, but some IdPs may use different ones.
+9. Select your client configuration and click **Edit**.
+10. Select the scopes expected by your OIDC IdP. The standard scopes are `openid`, `profile`, and `email`, but some IdPs may use different ones.
     * If you need refresh tokens for your end-users, you also need the `offline_access` scope.
     * Add other scopes as needed.
-10. Select your user parsing. By default, this module will use standard OpenID claims to provision end-users in your app. Also included is a flow that uses the standard UserInfo endpoint in OIDC, which is useful in the case that your IdP uses thin tokens. You can set up user provisioning by setting the following standard flows:
+11. Select your user parsing. By default, this module will use standard OpenID claims to provision end-users in your app. Also included is a flow that uses the standard UserInfo endpoint in OIDC, which is useful in the case that your IdP uses thin tokens. You can set up user provisioning by setting the following standard flows:
 
     | Default Microflow | Use |
     | --- | --- |
@@ -372,7 +373,7 @@ In this case, the OIDC client is the app you are making.
 
     {{% alert color="info" %}}Starting from UserCommons version 2.0.0, If the IdP does not specify the timezone and language for newly created users, these settings will be set according to default **App Settings** of your app. If no default is available, they remain unset. Existing users retain their previously set values.{{% /alert %}}
 
-11. Optionally, you can select the `CustomAccessTokenParsing` microflow if you want to use additional information from the OIDC IdP. This can be used, for example, to assign end-user roles based on information from the IdP – see [Dynamic Assignment of Userroles (Access Token Parsing)](#access-token-parsing) for more information.
+12. Optionally, you can select the `CustomAccessTokenParsing` microflow if you want to use additional information from the OIDC IdP. This can be used, for example, to assign end-user roles based on information from the IdP – see [Dynamic Assignment of Userroles (Access Token Parsing)](#access-token-parsing) for more information.
 
     {{% alert color="info" %}}Starting from version 4.0.0 of the OIDC SSO, the default user roles in the UserProvisioning will be assigned alongside the roles parsed from the access token.{{% /alert %}}
 
@@ -503,6 +504,8 @@ when you set **ClientAuthenticationMethod** as `private_key_jwt`, you do not nee
 
     Example: `acr1 acr2`
 
+* **EnablePKCE** (*default: True*) – enables Proof Key for Code Exchange (PKCE)
+
 ##### Deploy-time IdPs for API Security Only Configuration
 
 {{% alert color="info" %}}
@@ -521,6 +524,20 @@ Example: `OIDC.Default_SAM_TokenProcessing_CustomATP`
 When the `IsClientGrantOnly` constant is set to *true*, the OIDC SSO module considers the configuration as Client Credential grant configuration.
 {{% /alert %}}
 
+## Configuring Multi-Domain {#multi-domain}
+
+The OIDC SSO module supports multi-domain, enabling flexible deployment in multi-app or shared domain environments. When you enable multi-domain support, the module resolves the application URL from request headers rather than relying solely on the ApplicationRootUrl, allowing users to access the application through their custom domains.
+
+To enable multi-domain support, set the `EnableMultiDomainSupport` constant to *True* in the [Acceptance Environment Details](/developerportal/deploy/environments-details/#constants) for Mendix Cloud. By default, this constant is set to *False*.
+
+After enabling multi-domain support, configure the `AllowedHosts` constant to specify which custom domains are permitted. If you enable multi-domain support but leave `AllowedHosts` empty, the module redirects all users to the ApplicationRootUrl.
+
+The `AllowedHosts` constant accepts a comma-separated or space-separated list of hostnames in the following formats:
+
+* Exact match – `example.com` allows only that specific domain
+* Subdomain wildcard – `.example.com` allows any subdomain of `example.com`
+* Full wildcard – `*` allows any domain
+
 ## User Provisioning (End-User Onboarding)
 
 Initially, your app will not have any end-users. You can onboard end-users into your app using one of the following mechanisms: 

content/en/docs/releasenotes/deployment/_index.md

@@ -15,7 +15,7 @@ Follow the links in the table below to see the release notes you want:
 
 | Type of Deployment | Last Updated |
 | --- | --- |
-| [Mendix Cloud](/releasenotes/developer-portal/mendix-cloud/) | June 7, 2026 |
+| [Mendix Cloud](/releasenotes/developer-portal/mendix-cloud/) | June 9, 2026 |
 | [Mendix on Kubernetes](/releasenotes/developer-portal/mendix-for-private-cloud/) | February 5, 2026 |
 | [Mendix on Azure](/releasenotes/developer-portal/mendix-on-azure/) | January 29, 2026 |
 | [SAP Business Technology Platform (SAP BTP)](/releasenotes/developer-portal/sap-cloud-platform/) | September 28, 2025 |

content/en/docs/releasenotes/deployment/mendix-cloud/2026.md

@@ -7,6 +7,16 @@ weight: 1
 ---
 ## June 2026
 
+### June 9, 2026
+
+#### Improvements
+
+* Mendix Cloud database backups are now created with `pg_dump` version `1.16`. This version has been included with PostgreSQL since September 2024 as part of PostgreSQL 17. As a result, backups created in Mendix Cloud can only be restored with `pg_restore` version `1.16` or above (PostgreSQL 17 or above).
+
+    If you attempt to restore a backup using an earlier version, you will receive the following error: `pg_restore: [archiver] unsupported version (1.16) in the file header`. To resolve this issue, upgrade your software to a version that includes newer versions of `pg_dump` and `pg_restore`. 
+
+    Backups created in Mendix Cloud before June 9, 2026, continue to work as expected after you upgrade your local PostgreSQL binaries to newer versions.
+
 ### June 7, 2026
 
 #### Bug Fixes

content/en/docs/releasenotes/deployment/mendix-for-private-cloud.md

@@ -12,7 +12,15 @@ For information on the current status of deployment to Mendix on Kubernetes and
 
 ## 2026
 
-### May 20, 2026
+### June 11, 2026
+
+#### License Manager CLI v0.10.11 {#0.10.11}
+
+* We have updated the components to use the latest dependency versions in order to improve security score ratings for container images.
+
+#### Mendix Operator v2.27.1 {#2.27.1}
+
+* We have updated the components to use the latest dependency versions in order to improve security score ratings for container images.
 
 ### June 4, 2026
 

content/en/docs/releasenotes/feature-release-calendar/_index.md

@@ -34,7 +34,7 @@ General Availability means that a feature is available for all users. This type
 | Model Agents as part of your Workflow | General Availability: Mx 11.9 |
 | Dynamic Case Management | Private Beta: Mx 11.3 <br/>Limited Availability: Mx 11.12 |
 | Global Inbox Workflow Tasks | General Availability: Mx 11.9 |
-| Global Inbox Other Tasks | General Availability: Mx 11.12 |
+| Global Inbox Other Tasks | General Availability: Mx 11.14 |
 | Workflow Non-interrupting Event Subprocesses (Message trigger) | Public Beta: Mx 11.8 <br/>General Availability: Mx 11.9 |
 | Workflow Interrupting Event Subprocesses (Message trigger) | General Availability: Mx 11.10 |
 | Workflow Interrupting Event Subprocesses (Timer trigger) | General Availability: Mx 11.14 |