idp_managed admin updates

content/en/docs/control-center/security/security.md

@@ -73,7 +73,7 @@ You can turn application data replication back on by clicking **Activate**.
 
 On the **Single Sign-On** tab, you can set up an identity federation between the Mendix Platform and your corporate identity provider. This feature is called [Bring Your Own Identity Provider (BYOIDP)](/control-center/security/set-up-sso-byoidp/).
 
-### IdP-managed Mendix Admins
+### IdP-managed Mendix Admins {#idp-managed-mendix-admins}
 
 Once you have set up Single Sign-On (SSO) for the Mendix platform, you can extend this Identity Provider (IdP) integration to control who is granted the Mendix Admin role. From an access management perspective, central management of privileged roles, such as the Mendix Admin, is a recognized best practice. This approach mitigates the risk of privilege creep, where existing Mendix Admins can freely give admin rights to others without proper control.
 
@@ -96,18 +96,20 @@ As a result, the overview of [Mendix Admins](/control-center/mendix-admins-page/
 
 #### Onboarding Prerequisites
 
-Before you request to be onboarded to the IdP-managed Mendix Admins feature, please ensure the following prerequisites are met:
+Before you request to be onboarded to the IdP-managed Mendix Admins feature, ensure the following prerequisites are met:
 
-1. You have a Premium platform license to use this feature.
+1. You have a premium platform license to use this feature.
 2. You have set up an active SSO or BYO-IdP configuration, as described in [Set Up an SSO (BYOIDP)](/control-center/security/set-up-sso-byoidp/).
-3. You have a user group in your IdP that includes your current Mendix Admins. Typically, your IT department should manage this group, possibly with a request/approval process.
+3. You have a user group in your IdP that includes your current Mendix Admins. Typically, your IT department should manage this group, possibly with a request or approval process.
 4. The ID token sent by your IdP to the Mendix platform during SSO must include a claim that indicates whether a user is a member of the Mendix Admin group. For configuration, Mendix needs to know the name of the claim and the expected value. When using Entra ID, a typical setup should have the following claim in the ID token:
 
     ```text
     “roles” : “Mendix-admin”
     ```
 
-The Mendix platform has the flexibility of using any claim name and value.
+    The Mendix platform has the flexibility of using any claim name and value.
+
+5. Note that when using the BYOIDP feature to manage your Mendix Admins (see the [IdP-managed Mendix Admins](#idp-managed-mendix-admins) section above), the Mendix platform does not include anything specific in the SSO request (such as a specific scope value or claims request parameter). It expects that your IdP includes the required claim based on the configurations in your IdP for Mendix as a client.
 
 ## Security History Tab
 

content/en/docs/control-center/security/set-up-sso-byoidp.md

@@ -56,8 +56,10 @@ BYOIDP SSO integrates with the Mendix Platform using the following techniques:
     * This assumes that the IdP returns an email address to Mendix during SSO which the user previously used to sign up and log in to Mendix. If the email address that is returned to Mendix is not recognized, then the user will be offered the sign-up option to enable them to create a new account.
 * BYOIDP SSO makes an authentication request to your IdP which means that only the 'openid' and 'profile' scope values are requested, as defined by OIDC. The request does not explicitly ask for authorization for specific platform roles such as developer, Mendix Admin, or Technical Contact. You can set up your IdP, however, to apply coarse-grained access rules based on the `client_id` for the Mendix Platform to deny access to the Mendix Platform for certain groups of employees.
 * Mendix provides support for three client authentication methods: `client_secret_post` (client credentials in the payload), `client_secret_basic` (basic authentication credentials in the HTTP header), and `private_key_jwt` (using a client key-pair/certificate instead of a client secret). The Mendix platform will select `client_secret_post` if supported; otherwise, it will use `client_secret_basic`. The `private_key_jwt` method is available only to customers with a Premium platform license and requires onboarding by Mendix. For further assistance, contact your CSM.
-* Mendix includes the `login_hint` parameter in requests to your IdP This allows the IdP to pre-populate the login screen with the user's email address, which gives a better user experience. Your IdP may choose to ignore the hint. After receiving a positive response, Mendix does not do any validation if the logged-in user matches the login_hint.
+* Mendix includes the `login_hint` parameter in requests to your IdP. This allows the IdP to pre-populate the login screen with the user's email address, which gives a better user experience. Your IdP may choose to ignore the hint. After receiving a positive response, Mendix does not do any validation if the logged-in user matches the `login_hint`.
 * Whether or not users signing in to the Mendix Platform have to use 2FA does not change the [Two-Factor Authentication](/developerportal/deploy/two-factor-authentication/) which protects sensitive activities on Mendix Cloud nodes. This remains in place and works independently of BYOIDP SSO.
+* When using the BYOIDP feature to manage your Mendix Admins (see the [IdP-managed Mendix Admins](/control-center/security-settings/#idp-managed-mendix-admins) section of *Security Settings in Control Center*), the Mendix platform does not include anything specific in the SSO request (such as a specific scope value or claims request parameter). It expects that your IdP includes the required claim based on the configurations in your IdP for Mendix as a client.
+* Your group claim can have multiple values. Mendix checks the list to find the configured value.
 
 ### Limitations