diff --git a/content/en/docs/appstore/use-content/platform-supported-content/modules/oidc.md b/content/en/docs/appstore/use-content/platform-supported-content/modules/oidc sso/_index.md similarity index 76% rename from content/en/docs/appstore/use-content/platform-supported-content/modules/oidc.md rename to content/en/docs/appstore/use-content/platform-supported-content/modules/oidc sso/_index.md index 242eae2199a..d829fc5feab 100644 --- a/content/en/docs/appstore/use-content/platform-supported-content/modules/oidc.md +++ b/content/en/docs/appstore/use-content/platform-supported-content/modules/oidc sso/_index.md @@ -41,9 +41,7 @@ Alternatives to using OIDC SSO for managing single sign-on are: * **Works with Responsive web app and PWA:** OIDC SSO module supports both responsive web apps and progressive web apps (PWA), ensuring seamless functionality in both offline and online modes for PWAs. If you are building a native mobile app, you need to use [Mobile SSO](https://marketplace.mendix.com/link/component/223516) module for your app. For more information, see [Building a Responsive Web App](/quickstarts/responsive-web-app/), [Progressive Web App](/refguide/mobile/introduction-to-mobile-technologies/progressive-web-app/), and [Native Mobile](/refguide/mobile/introduction-to-mobile-technologies/native-mobile/). * **API security:** If your app exposes APIs, such as an OData API, it is best security practice to use OAuth Access Tokens (also known as bearer tokens or JWT tokens) instead of Basic Authentication or API keys. You can use the OIDC SSO module to validate these Access Tokens and check if they have right authorization (i.e., the right OAuth scopes) for accessing your API endpoint. For example, you may want to allow a specific user or client to perform a GET (read) request but not a POST or PATCH (write) request. The OIDC module supports processing Access Tokens obtained via both SSO and the OAuth client credential grant. -### Features and Limitations - -#### Features +### Features The OIDC SSO module supports the following features: @@ -66,7 +64,7 @@ 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) + * 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 [User Provisioning Using a Microflow at Runtime.](/appstore/modules/oidc/oidc-user-provisioning/#microflow-at-runtime) * 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. @@ -76,7 +74,24 @@ The OIDC SSO module supports the following features: * Built primarily in standard Mendix components (minimal Java) to allow for easy customization and ongoing development. -#### OIDC Protocol Adherence +### Limitations + +The OIDC SSO module does not yet support the following: + +* Requesting claims via the 'claims' query parameter, as per OIDC specs +* Other client authentication methods such as using asymmetric keys (“private_key_jwt”) +* Delegating authorization using OAuth-scopes; this currently requires a custom microflow for parsing of Access Tokens +* Mobile apps +* Controlling the configuration using constants requires an app restart + +The OIDC SSO module also has the following limitations: + +* If an end-user accesses your app via a deeplink, the end-user is not already signed in, and you have configured multiple IdPs, only one IdP can be used to sign the end-user in. +* 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. + +### OIDC Protocol Adherence For readers with more knowledge of the OAuth and OIDC protocol: @@ -98,23 +113,6 @@ For readers with more knowledge of the OAuth and OIDC protocol: * Helps you implement an OAuth Resource Server that receives an Access Token which is obtained by a client via either Authorization Code grant or Client Credential grant. * When the OIDC SSO module secures an API with the Client Credential grant, the `sub` as claim (which contains either user-id or client-id) should always be available in the access token as per [RFC 9068](https://datatracker.ietf.org/doc/html/rfc9068#name-data-structure). If it is not included, the module will look for `client_id`. To be compliant with Microsoft's Entra ID and Okta, it will use `app_id` or `cid` as alternatives to `client_id`. Any of these client identifiers are used to create a user in the Mendix application, allowing the Mendix security model to apply not only to users (human identities) but also to clients (machine identities). -#### Limitations - -The OIDC SSO module does not yet support the following: - -* Requesting claims via the 'claims' query parameter, as per OIDC specs -* Other client authentication methods such as using asymmetric keys (“private_key_jwt”) -* Delegating authorization using OAuth-scopes; this currently requires a custom microflow for parsing of Access Tokens -* Mobile apps -* Controlling the configuration using constants requires an app restart - -The OIDC SSO module also has the following limitations: - -* If an end-user accesses your app via a deeplink, the end-user is not already signed in, and you have configured multiple IdPs, only one IdP can be used to sign the end-user in. -* 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. - ## Dependencies The OIDC module requires your app to be using Mendix 9.0 or above. @@ -262,82 +260,76 @@ To connect your App with your IdP, you need to configure both your IdP (as descr * `https:///oauth/v2/callback` * `makeitnative:///oauth/callback` -#### Microsoft Entra ID Provider Configuration for APIs{#azure-portal} - -This section gives some guidance for doing the necessary configurations at your entra ID provider to obtain access tokens containing the right authorization claims to secure your APIs. - -If you do not set the access token up correctly, you will get access tokens containing default `aud` (audience) claims. The default audience is the Microsoft Graph API and so these access tokens cannot be validated by your API. - -To get the Microsoft Identity Platform to issue access tokens you can pass to your API, you need to set up a custom scope in the App Registration’s **Expose an API** tab, and request that scope when you acquire the tokens. To do this, follow the steps below: - -1. Open the **Expose an API** tab in the **App Registration** page of the Azure Portal. -1. In the **Expose an API** tab, set up a custom scope. - The scope will be prefixed with your `Application ID URI`. -1. In the **API permissions** tab, assign the created scope to the application. -1. In the **App roles** tab, add the user roles you want to authorize using either the user role name, or the user role UUID. This adds the configured user roles to the roles claim in the access token. +### Runtime Configuration of Your IdP at Your App {#runtime-idp-app} -By adding a custom claim to the App Registration’s Expose an API tab and requesting that scope when we acquire tokens, the Microsoft Identity Platform will now generate access tokens that can be validated using the `/jwks` URI. +This section describes how you can configure your IdP in your Mendix app using the Admin UIs provided by the OIDC SSO module. These screens offer below tabs: -#### Amazon Cognito Provider Configuration +* **IdPs for SSO and API security** +* **IdPs for API security only** -For information about configuring Amazon Cognito for the OIDC SSO module, see [Amazon Cognito: Configuring Amazon Cognito](/appstore/modules/aws/amazon-cognito/#cognito-provider). +{{< figure src="/attachments/appstore/platform-supported-content/modules/oidc/runtime-config.png" class="no-border" >}} -### Runtime Configuration of Your IdP at Your App {#runtime-idp-app} +You can configure your OIDC client using the app pages – see [General OIDC Clients](#general-oidc), [Microsoft Entra ID Client Configuration for APIs](#azure), and [Amazon Cognito](/appstore/modules/aws/amazon-cognito/). In version 2.3.0 and above, you can also use constants to configure your app at deployment time – see [Automated Deploy-time Configuration of Your IdP at Your App](#deploytime-idp-configuration), below. -This section describes how you can configure your IdP in your Mendix app using the Admin UIs provided by the OIDC SSO module. These screens offer two tabs: +#### IdPs for SSO and API Security -* **IdPs for SSO and API security**: Use this more extensive configuration screen if you are implementing SSO and optionally API security. -* **IdPs for API security only**: Use this simpler configuration screen if you are configuring an IdP that is only used for API security (i.e., Client Credential grant). For more information, see the [API Security Configuration for Client Credential Grant](#client-credential-grant) section below. +Use this more extensive configuration screen if you are implementing SSO and optionally API security. Start your app, log in as an administrator, for example *demo_administrator*, and access the **IdPs for SSO and API security** setup page. Click **New** to add a new client configuration and access the **Configuration** tab. -You can configure your OIDC client using the app pages – see [General OIDC Clients](#general-oidc), [Microsoft Entra ID Client Configuration for APIs](#azure), and [Amazon Cognito](/appstore/modules/aws/amazon-cognito/). In version 2.3.0 and above, you can also use constants to configure your app at deployment time – see [Automated Deploy-time SSO Configuration](#deploy-time), below. +{{% alert color="info" %}}Additionally, you can see the **UserProvisioning** tab to provision your end users. For more information, see the [OIDC SSO User Provisioning](/appstore/modules/oidc/oidc-user-provisioning/).{{% /alert %}} -#### General OIDC Clients {#general-oidc} +##### General OIDC Clients {#general-oidc} -In this case, the OIDC client is the app you are making. +In this case, the OIDC client is the app you are making. In the **Configuration** tab, you need to configure the following fields: -1. Start your app, log in as an administrator, for example *demo_administrator*, and access the **IdPs for SSO and API security** setup page. -2. Add a new client configuration and give it an **Alias** so you can identify it if you have more than one client configuration. -3. Add the **Client ID**. +1. Give an **Alias** so you can identify it if you have more than one client configuration. +2. Add the **Client ID**. - **Client assertion** is automatically set to *Client ID and Secret*. + 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. +3. 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. (Default – for security reasons this should be your preferred choice) * `client_secret_post`: Your app will authenticate itself by including its `client_id` and `client_secret` in the payload of token requests. (Older versions of the OIDC SSO module used this method). -5. Add the **Client Secret**. -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. +4. Add the **Client Secret**. +5. 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** +6. 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. +7. Select your client configuration and click **Edit**. +8. 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: +9. 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 | | --- | --- | - | OIDC_CustomUserParsing_Standard | It implements some standard OpenID claims to find/provision a user. | - | OIDC_CustomUserParsing_UserInfo | It is similar as standard OIDC user parsing flow, except it works with identity providers that use `opaque` tokens. | - | OIDC_CustomUserParsing_Salesforce | It offers an `id` endpoint that retrieves information about user. You can use OpenID token (`id_token`) to map user attributes. | + | OIDC_CustomUserParsing_Standard
(renamed from UserProvisioning_Standard)| It implements some standard OpenID claims to find/provision a user. | + | OIDC_CustomUserParsing_UserInfo
(renamed from UserProvisioning_UserInfo)| It is similar as standard OIDC user parsing flow, except it works with identity providers that use `opaque` tokens. | + | OIDC_CustomUserParsing_Salesforce
(renamed from UserProvisioning_Salesforce)| It offers an `id` endpoint that retrieves information about user. You can use OpenID token (`id_token`) to map user attributes. | - In version below 3.0.0 of the OIDC SSO module, you can configure the timezone and language using the `OIDC_CustomUserParsing_Standard` and `OIDC_CustomUserParsing_UserInfo` microflow. However, in version 3.0.0 and above of the OIDC SSO module, you can set the timezone and language using any standard microflow. + {{% alert color="info" %}}In version 3.0.0 and above you can write your own custom userparsing microflow prefixed with `OIDC_CustomUserParsing`. It should return a `System.User` object. +
+ In version below 3.0.0 of the OIDC SSO module, you can configure the timezone and language using the `UserProvisioning_Standard` and `UserProvisioning_UserInfo` microflow. However, in version 3.0.0 and above, you can set the timezone and language using any user parsing microflow. + {{% /alert %}} - You can also use your own custom user entity to manage users of the app. See the section on [Custom User Provisioning](#custom-provisioning) for more information on what you can do to implement provisioning logic which fits your business needs. The module includes a Salesforce-specific example. + You can also use your own custom user entity to manage users of the app. See the section on [OIDC SSO User Provisioning](/appstore/modules/oidc/oidc-user-provisioning/) for more information on what you can do to implement provisioning logic which fits your business needs. The module includes a Salesforce-specific example. -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 [Access Token Parsing](#access-token-parsing) for more information. +10. 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 [Access Token Parsing](#access-token-parsing) for more information. Once you have completed these steps, the SSO-configuration is ready for testing. For more information, see the [Testing and troubleshooting](#testing) section. See the section [Optional Features](#optional) information on additional optional features you may want to implement. -#### API Security Configuration for Client Credential Grant {#client-credential-grant} +#### IdPs for API Security Only + +Use this simpler configuration screen if you are configuring an IdP that is only used for API security (i.e., Client Credential grant). For more information, see the [API Security Configuration for Client Credential Grant](#client-credential-grant) section below. + +##### API Security Configuration for Client Credential Grant {#client-credential-grant} 1. Start your app, log in as an administrator, for example *demo_administrator*, and access the Client Credential setup page. 2. 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. @@ -348,24 +340,9 @@ See the section [Optional Features](#optional) information on additional optiona 3. 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 [Access Token Parsing](#access-token-parsing) for more information. 4. Click Save. Once you have completed these steps, the Client Credential Configuration is ready for testing. -#### Microsoft Entra ID Client Configuration for APIs {#azure} - -For Entra ID access to APIs through an access token, in addition to the configuration described above, we can request the scope [configured in Azure portal](#azure-portal), described above, from the OIDC SSO UI configuration. +{{< figure src="/attachments/appstore/platform-supported-content/modules/oidc/client-credential-grant.png" class="no-border" >}} -1. Start your app, log in as an administrator, for example *demo_administrator*, and access the **IdPs for API security only** Setup page. -1. Add the custom scope which you [configured in Azure](#azure-portal) in **Available scopes**. -1. Save the configuration. -1. Edit the Entra ID configuration and add the custom scope to **Selected scopes**. - -Now, you can acquire tokens which can be validated using JWKS URI. - -#### Amazon Cognito Client Configuration - -For more information about configuring your app for OIDC with Amazon Cognito, see [Amazon Cognito: Configuring the Required Settings in Your Mendix App](/appstore/modules/aws/amazon-cognito/#cognito). - -### Deploytime Configuration of Your IdP at Your App{#deploytime-idp-configuration} - -#### Automated Deploy-time SSO Configuration{#deploy-time} +### Automated Deploy-time Configuration of Your IdP at Your App{#deploytime-idp-configuration} In version 2.3.0 and above, you can configure the OIDC SSO module using app [constants](/refguide/constants/) rather than using the app administration pages. As the developer of an app using OIDC SSO, you can set default values. These values can be overridden using the app constants. @@ -387,15 +364,15 @@ The following error messages will be displayed when you try to edit/delete. * error at delete: You cannot delete as it is created from deployment. {{% /alert %}} -##### Customizing Default Deploy-time Configuration +#### Customizing Default Deploy-time Configuration -By default, the `Custom_CreateIDPConfiguration` microflow in the **MOVE_ME** folder of the OIDC module uses the `Default_CreateIDPConfiguration` microflow. Review the microflow `Custom_CreateIDPConfiguration` in the **MOVE_ME** folder. This is where you can change the default IdP configuration at Deploytime Configuration. +By default, the `Custom_CreateIDPConfiguration` microflow in the **MOVE_ME** folder of the OIDC module uses the `Default_CreateIDPConfiguration` microflow. Review the microflow `Custom_CreateIDPConfiguration` in the **MOVE_ME** folder. This is where you can change the default IdP configuration by replacing `Default_CreateIDPConfiguration` with your own custom microflow at deploy-time configuration. In this configuration, you have several options to customize the Identity Provider (IdP) settings. Firstly, you can configure the IdP using constants. Additionally, the OIDC module supports further customization of the IdP configuration through the implementation of a custom microflow called `Custom_CreateIdPConfiguration`. This microflow returns a list of configured IdPs, which the OIDC module then uses to generate the necessary SSO configurations for multiple IdPs. In this non-default configuration method, users have the flexibility to introduce your own constants by creating custom IdP configurations. -##### Deploy-time IdPs for SSO and API Security Configuration +#### Deploy-time IdPs for SSO and API Security Configuration {{% alert color="info" %}} **IdPs for SSO and API security** configuration supports both Authorization code and Client Credential grant type. @@ -408,7 +385,7 @@ The following constants are mandatory when creating an OIDC SSO IdP configuratio * **ClientSecret** – the client secret (see security best-practice, above) * **AutomaticConfigurationURL** – the URL of the well-known endpoint (ending with `/.well-known/openid-configuration`) -For more information on creating user provisioning with constants, see the [Deploy-time User Provisioning Configuration](#custom-provisioning-dep) section below. +For more information on creating user provisioning with constants, see the [User Provisioning at Deploy-time](/appstore/modules/oidc/oidc-user-provisioning/#custom-provisioning-dep) section of the *OIDC SSO User Provisioning*. The following constants are optional: @@ -444,7 +421,7 @@ The following constants are optional: Example: `acr1 acr2` -##### Deploy-time IdPs for API Security Only Configuration +#### Deploy-time IdPs for API Security Only Configuration {{% alert color="info" %}} **IdPs for API security only** configuration supports Client Credential grant type only. @@ -462,157 +439,42 @@ 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 %}} -## User Provisioning - -Initially your app will not have any end-users. The OIDC module provides so-called Just-In-Time (JIT) user provisioning. This means that an end-user will be created in your app when they log in for the first time. If you do not want JIT user provisioning, it is possible to disable it as described in the section [Custom User Provisioning at Runtime](#custom-provisioning-rt). - -By default, end-users are provisioned using the `Account` object in the Administration module. If you need to use a custom user entity you can do this via [Custom User Provisioning Using a Microflow](#custom-provisioning-mf) or (in version 3.0.0 and above) [Deploy-time User Provisioning Configuration](#custom-provisioning-dep) or [Custom User Provisioning at Runtime](#custom-provisioning-rt). - -### Default User Provisioning - -By default, the `CUSTOM_UserProvisioning` microflow in the **USE_ME** > **1. Configuration** folder of the OIDC module uses the `OIDC_CustomUserParsing_Standard` microflow. This applies the following mapping: - -| ID-token Provided by your IdP | Attribute of `Administration.Account` Object | -| ----------------------------- | ----------------------------- | -| sub | Name | -| name | Fullname | -| email | Email | - -{{% alert color="warning" %}} -Do not change the `OIDC_CustomUserParsing_Standard` microflow. This may give problems if you upgrade to a newer version of the OIDC SSO module. Apply customizations to the `CUSTOM_UserProvisioning` microflow only. -{{% /alert %}} - -### Custom User Provisioning{#custom-provisioning} - -If you create custom user entities as specializations of the `System.User` entity, you can store user information that is more extensive than is possible with the `System.User` or `Administration.Account` entities. You can use these specializations as target entities for end-user provisioning using one of the methods described below. - -If you connect multiple IdPs to your Mendix app, you can use separate custom user entities for each IdP, each with its own attribute mapping. - -#### Custom User Provisioning Using a Microflow{#custom-provisioning-mf} - -{{% alert color="warning" %}} -This feature is deprecated from the version 3.0.0 of the module. -{{% /alert %}} - -Review the microflow `CUSTOM_UserProvisioning` in the **USE_ME** > **1. Configuration** folder of the OIDC module. This is where you can change the way that end-users are provisioned in your app. The OpenID token is passed to the microflow as a parameter. Use this object to find an existing, or create a new, `System.User` object for the end-user. This is set as the return value of the microflow. You can find examples included in the **USE_ME** > **1. Configuration** > **User Provisioning Examples** folder. - -Make a single call from `CUSTOM_UserProvisioning` to your own module where you implement the provisioning flow you need. This way, it will be easy to install new versions of the OIDC SSO module over time without overwriting your custom provisioning. - -The OIDC SSO module supports multiple IdPs. Since each provider can provide user data in a different format, you may want to use multiple provisioning flows. The microflow should contain the prefix `OIDC_CustomUserParsing`. See the microflow `UserProvisioning_Sample` for an example and details on how to do this. - -#### Deploy-time User Provisioning Configuration{#custom-provisioning-dep} - -{{% alert color="info" %}} -This feature is available in version 3.0.0 and above -{{% /alert %}} - -You can set up custom user provisioning by setting constants when you deploy your app. This has the following limitations compared to setting up provisioning using a microflow or changing the settings at runtime: - -* You need to restart your app to apply changes to the constants -* You cannot set custom mapping of IdP claims to attributes of your custom user entity - -You can set up custom user provisioning by setting the following constants. You can set default values when you build your app, but can override these in the app's environment. - -| Constant | Use | Notes | Example | -| --- | --- | --- | --- | -| CustomUserEntity | a custom user entity | in the form `modulename.entityname` – a specialization of `System.User` | `Administration.Account` | -| PrincipalEntityAttribute | the attribute holding the unique identifier of an authenticated user | | `Name` | -| PrincipalIdPAttribute | the IdP claim which is the unique identifier of an authenticated user | | `sub` | -| AllowcreateUsers | allow to create users in the application | *optional* | `True` | -| Userrole | the role which will be assigned to newly created users | *optional* - Default Userrole is assigned only at user creation
- User updates do not change the default role
- No bulk update for existing users when the default userrole changes | `User` | -| UserType | assign usertype to the created users | *optional* | `Internal` | -| CustomUserProvisioning | a custom microflow to use for user provisioning | *optional* – in the form `modulename.microflowname` – the microflow name must begin with the string `UC_CustomProvisioning` | `Mymodule.UC_CustomProvisioning` | - -#### Custom User Provisioning at Runtime{#custom-provisioning-rt} - -{{% alert color="info" %}} -This feature is available in version 3.0.0 and above -{{% /alert %}} - -You can set up custom user provisioning once your app is running using the `OIDC.OIDC_Client_Overview` page that you set up for the administrator for the app in [Configuring Navigation](#configure-nav). You can set up custom user provisioning as follows: - -1. Sign in to the running app with an administrator account. -2. Navigate to the `OIDC.OIDC_Client_Overview` page set up in the app navigation. -3. Select the **Provisioning** tab. -4. Set up the following information: +### IdP Configuration for Microsoft Entra ID and Amazon Cognito - * **Custom user Entity (extension of System.User)** – the Mendix entity in which you will store and look up the user account. If you are using the [Administration module](https://marketplace.mendix.com/link/component/23513), this would be `Administration.Account`. - * **The attribute where the user principal is stored** – unique identifier associated with an authenticated user. - * **Allow the module to create users** – this enables the module to create users based on user provisioning and attribute mapping configurations. When disabled, it will still update existing users. However, for new users, it will display an exception message stating that the login action was successful but no user has been configured. - * By default, the value is set to ***Yes***. - * **User role** – the role which will be assigned to newly created users. You can select one default user role. If you need additional user roles, use Access Token Parsing microflow to assign multiple roles. - * **User Type** – this allows you to configure end-users of your application as internal or external. - * By default, the value is set to ***Internal***. +The section below shows you how to configure both your IdP and your Mendix application for the Entra ID and Amazon Cognito IdPs. -5. Under **Attribute Mapping**, for each piece of information you want to add to your custom user entity, select an **IdP Attribute** (claim) and specify the **Configured Entity Attribute** where you want to store the information. +#### Configuring Microsoft Entra ID - Note the following: +##### Microsoft Entra ID Provider Configuration for APIs{#azure-portal} - * You cannot use the IdP claim which is the primary attribute identifying the user and you cannot use the attribute you set in **The attribute where the user principal is stored**. - * You can map multiple **IdP Attribute** (claims) to a **Configured Entity Attribute** but you cannot map a new **IdP Attribute** to a **Configured Entity Attribute** if it is already mapped. - * The **IdP Attribute** is one of the fixed claims supported by the OIDC SSO module. - * IdP Attributes(Claims) cannot be of type enum, autonumber, or an association. - * The image below shows you the default attribute mapping for the configuration. - - {{< figure src="/attachments/appstore/platform-supported-content/modules/oidc/default_mapping.png" max-width=80% >}} - -6. Optionally, you can use the custom logic in the **User Provisioning**. In the **Custom UserProvisioning** field, select a microflow you want to run for custom user provisioning. The custom microflow name must begin with the string `UC_CustomProvisioning` and requires the following parameters: - - 1. **UserInfoParameter(UserCommons.UserInfoParam)**: A Mendix object containing user claims information through its associated objects. You can use this parameter to retrieve user provisioning configuration information. - 2. **User(System.User)**: A Mendix object representing the user to be provisioned. Ensure that the selected microflow matches this parameter signature. - - The microflow must return a **System.User** object to ensure proper user provisioning and updates. It will be executed after user creation or update of user. If you have added a new microflow, you will need to refresh the module containing your microflow as described in the [Installing Mx Model Reflection](#mxmodelreflection). This selection can be blank if you do not want to add custom logic. - -7. Click **Save** to save the configuration. - - {{< figure src="/attachments/appstore/platform-supported-content/modules/oidc/user commons.png" max-width=80% >}} - -### Evaluating Multiple User Matches - -Review the custom microflow `evaluateMultipleUserMatches` in the **USE_ME** folder. The module tries to find the user corresponding to the given username. This microflow is triggered when multiple matching `System.User` records are found. - -You can customize this microflow to determine the correct user. The resulted user instance will be signed in to the application and passed on to any other microflow. However, Mendix recommends using provided unique entity attribute only. For example, `System.User.Name`. - -### User Identifiers in the OIDC and SCIM Protocols - -This section provides an overview and general guidance on User Identifiers, essential for understanding how they function in the OIDC and SCIM protocols. It is particularly relevant for Entra ID customers to ensure proper implementation and alignment of User Identifiers. - -#### Overview of User Identifier - -When using OIDC SSO with Entra ID, user identifiers need to be configured correctly to ensure forward compatibility, especially if you plan to introduce the SCIM module in your application. If you are using OIDC SSO with Entra ID, you can refer to the [Microsoft documentation on attribute mapping](https://learn.microsoft.com/en-us/entra/identity/app-provisioning/customize-application-attributes). - -Entra ID uses two immutable identifiers for a user: - -* The user’s object ID: The user's object ID uniquely identifies a user, making it ideal for crosslinking users across different applications. For example, B2E application used across the company can use the object ID as a unique identifier. -* The user’s pairwise unique identifier: It is also known as a locally unique identifier and is derived from the combination of the user's object ID and the application's identifier. This means it cannot be used to crosslink a user across different applications. For example, applications that need additional privacy can use locally unique identifiers to avoid cross linking of users. - -Role of user identifiers in OIDC and SCIM protocols: +This section gives some guidance for doing the necessary configurations at your entra ID provider to obtain access tokens containing the right authorization claims to secure your APIs. -* OIDC protocol can use both types of identifiers based on use case: +If you do not set the access token up correctly, you will get access tokens containing default `aud` (audience) claims. The default audience is the Microsoft Graph API and so these access tokens cannot be validated by your API. - * The ID token contains a `sub` claim, which includes the pairwise unique identifier (locally unique identifier). - * The ID-token also contains an `oid` claim, which includes the user’s object ID. +To get the Microsoft Identity Platform to issue access tokens you can pass to your API, you need to set up a custom scope in the App Registration’s **Expose an API** tab, and request that scope when you acquire the tokens. To do this, follow the steps below: -* SCIM: +1. Open the **Expose an API** tab in the **App Registration** page of the Azure Portal. +1. In the **Expose an API** tab, set up a custom scope. + The scope will be prefixed with your `Application ID URI`. +1. In the **API permissions** tab, assign the created scope to the application. +1. In the **App roles** tab, add the user roles you want to authorize using either the user role name, or the user role UUID. This adds the configured user roles to the roles claim in the access token. - * In the SCIM protocol, you typically want to use the object ID to identify a user. It is used as the value for the `externalID` claim in SCIM payloads by default. +By adding a custom claim to the App Registration’s Expose an API tab and requesting that scope when we acquire tokens, the Microsoft Identity Platform will now generate access tokens that can be validated using the `/jwks` URI. -#### Guidance on User Identifier{#guidance-user-identifier} +##### Microsoft Entra ID Client Configuration for APIs {#azure} -The default behavior for the OIDC SSO module is to persist the value of the `sub` claim in the system.user.name attribute. This is not forward compatible with the introduction of SCIM. Therefore, for B2E applications connected with Entra ID for SSO, Mendix recommends the following: +For Entra ID access to APIs through an access token, in addition to the configuration described above, we can request the scope [configured in Azure portal](#azure-portal), described above, from the OIDC SSO UI configuration. -* For any new application, use the `oid` claim as user identifier by modifying the user provisioning flow. This will allow you to introduce SCIM. -* For existing applications that do not persist user-specific application data (other than system.user or administration.account), modify the user provisioning flow to use the `oid` claim instead of the `sub` claim. Delete all system.user and administration.account records to remove old user data. This will re-provision the users, allowing you to introduce SCIM. -* For existing applications that do not need to use SCIM, you can continue to use default `sub` claim value or any other claim such as `preferred_username`. -* For existing applications where you want to introduce SCIM, you will need to define a migration strategy for the identifiers. +1. Start your app, log in as an administrator, for example *demo_administrator*, and access the **IdPs for API security only** Setup page. +1. Add the custom scope which you [configured in Azure](#azure-portal) in **Available scopes**. +1. Save the configuration. +1. Edit the Entra ID configuration and add the custom scope to **Selected scopes**. -#### Configuring `oid` Claim in the OIDC SSO +Now, you can acquire tokens which can be validated using JWKS URI. -By default, the `WellKnownendpoint` (Automatic configuration URL) does not include the `oid` claim in its metadata. You will need to manually configure the `oid` claim in the **UserProvisioning** tab of the OIDC SSO configuration using the steps below: +#### Configuring Amazon Cognito -1. Go to **Attribute Mapping** and click **New**. -2. Select **Search** and click **New**. -3. Create `oid` claim and map it to the Entity Attribute. +To configure your app at Amazon, see the [Configuring Amazon Cognito](/appstore/modules/aws/amazon-cognito/#cognito-provider) section and configuring at Mendix apps, see the [Configuring the Required Settings in Your Mendix App](https://docs.mendix.com/appstore/modules/aws/amazon-cognito/#cognito) section of the *Amazon Cognito.* ## API Authentication {#api-authentication} @@ -875,7 +737,7 @@ A standard logout action will end an end-user's Mendix session, but will not end To do this, add a menu item or button for your end-users that calls the nanoflow `ACT_Logout`. -### Using ACR to Request Authentication Method +### Using ACR for Authentication Method Request By default, the OIDC SSO module does not care how users are signed in at your IdP, that is left to the discretion of the IdP. In some cases your IdP may support different methods for end-users to be authenticated and your app may want to indicate a preference. @@ -920,7 +782,7 @@ Your IdP may have different ways of handling requests to use a specific authenti * Your IdP may honor what is requested on a ‘best effort’ basis and indicate the actual authentication method used in the ID-token that is sent to your app. * Your IdP may send an error response to your app if the requested authentication method was not possible for the user that was asked to login, for whatever reason. -When a user successfully signs in at your IdP, your IdP may or may not return an ACR claim in the ID-token. If your IdP returns the actual authentication method that was used in the ACR claim in the ID-token (and/or Access Token), you can create a [custom User Provisioning microflow](#custom-provisioning) (or [custom access token parsing microflow](#custom-parsing)) to grant or restrict access to specific resources or functionalities based on the level of authentication assurance. +When a user successfully signs in at your IdP, your IdP may or may not return an ACR claim in the ID-token. If your IdP returns the actual authentication method that was used in the ACR claim in the ID-token (and/or Access Token), you can create a [User Provisioning Using a Microflow at Runtime](/appstore/modules/oidc/oidc-user-provisioning/#microflow-at-runtime) (or [custom access token parsing microflow](#custom-parsing)) to grant or restrict access to specific resources or functionalities based on the level of authentication assurance. ## Testing and Troubleshooting{#testing} diff --git a/content/en/docs/appstore/use-content/platform-supported-content/modules/oidc sso/oidc-user-provisioning.md b/content/en/docs/appstore/use-content/platform-supported-content/modules/oidc sso/oidc-user-provisioning.md new file mode 100644 index 00000000000..3202bfb70cb --- /dev/null +++ b/content/en/docs/appstore/use-content/platform-supported-content/modules/oidc sso/oidc-user-provisioning.md @@ -0,0 +1,183 @@ +--- +title: "OIDC SSO User Provisioning" +url: /appstore/modules/oidc/oidc-user-provisioning +description: "Describes the configuration of the user provisioning in the OIDC SSO module, which is available in the Mendix Marketplace." +#If moving or renaming this doc file, implement a temporary redirect and let the respective team know they should update the URL in the product. See Mapping to Products for more details. +# Linked from https://marketplace.mendix.com/link/component/120371 +--- + +## Introduction + +Initially, your app will not have any end-users. The OIDC module provides Just-In-Time (JIT) user provisioning. This means an end-user will be created in your app when they log in for the first time. If you do not want JIT user provisioning, it is possible to disable it as described in the section [Custom User Provisioning at Runtime](#custom-provisioning-rt). + +By default, end-users are provisioned using the `Account` object in the Administration module. If you need to use a custom user entity you can do this via [User Provisioning at Runtime](#custom-provisioning-rt) or [User Provisioning at Deploy-time](#custom-provisioning-dep). + +## Configuring User Provisioning for Version 3.0.0 and Above + +### User Provisioning at Runtime{#custom-provisioning-rt} + +You can set up user provisioning as follows: + +1. Sign in to the running app with an administrator account. +2. Navigate to the `OIDC.OIDC_Client_Overview` page which is set up in the app navigation. +3. In the **IdPs for SSO and API security** tab, click **New** and access the **UserProvisioning** tab. +4. Set up the following fields: + + * **Custom user Entity (extension of System.User)** – the Mendix entity where you will store and look up the user account. If you are using the [Administration module](https://marketplace.mendix.com/link/component/23513), this would be `Administration.Account`. + * **The attribute where the user principal is stored** – unique identifier associated with an authenticated user. + * **Allow the module to create users** – this enables the module to create users based on configurations of user provisioning and attribute mapping. When disabled, it will still update existing users. However, for new users, it will display an exception message stating that the login action was successful but no user has been configured. + * By default, the value is set to ***Yes***. + * **User role** – the role which will be assigned to newly created users. You can select one default user role. If you need additional user roles, use Access Token Parsing microflow to assign multiple roles. + * **User Type** – this allows you to configure end-users of your application as internal or external. + * By default, the value is set to ***Internal***. + +5. Under **Attribute Mapping**, for each piece of information you want to add to your custom user entity, select an **IdP Attribute** (claim) and specify the **Configured Entity Attribute** where you want to store the information. + + Note the following: + + * You cannot use the IdP claim which is the primary attribute identifying the user and you cannot use the attribute you set in **The attribute where the user principal is stored**. + * You can map multiple **IdP Attribute** (claims) to a **Configured Entity Attribute** but you cannot map a new **IdP Attribute** to a **Configured Entity Attribute** if it is already mapped. + * The **IdP Attribute** is one of the fixed claims supported by the OIDC SSO module. + * IdP Attributes(Claims) cannot be of type enum, autonumber, or an association. + +6. Optionally, you can select the microflow in the **Custom UserProvisioning** field to use custom logic for user provisioning. For more information, see the [Customizing User Provisioning Using a Microflow at Runtime](#microflow-at-runtime) section below. + + {{% alert color="info" %}} +If you are using module version 3.2.0 and below, you will need to refresh the module containing your microflow as described in the [Installing Mx Model Reflection](/appstore/modules/oidc/#mxmodelreflection) and select the microflow in the **Custom UserProvisioning** field. + {{% /alert %}} + +7. Click **Save** to save the configuration. + +By default, users are provisioned by [Default User Provisioning Configuration](#default). Optionally, you can customize user provisioning by [Modifying default Attribute Mapping](#modify-default), [User Provisioning Using Your Custom User Entity](#custom_user_entity), or [User Provisioning Using a Microflow at Runtime](#microflow-at-runtime). + +{{% alert color="info" %}} +If you connect multiple IdPs to your Mendix app, you can use separate custom user entities for each IdP, each with its own attribute mapping. +{{% /alert %}} + +#### Default User Provisioning Configuration{#default} + +The User Provisioning configuration fields are available in the **UserProvisioning** tab. In default configuration, the custom user entity is set as `Administration.Account`, the principal attribute is set as `Name`, and the default attribute mapping is provided. + +{{< figure src="/attachments/appstore/platform-supported-content/modules/oidc/default_provisioning.png" max-width=80% >}} + +##### Modifying Default Attribute Mapping{#modify-default} + +Optionally, you can change the default **IdP Attribute** or the **Configured Entity Attribute**, by editing the mapping in the **Attribute Mapping** section within the **UserProvisioning** tab. + +#### User Provisioning Using Your Custom User Entity{#custom_user_entity} + +If you want to use your custom user entity which is a specialization of the `System.User` entity to store user information, select it in the **Custom user Entity (extension of System.User)** field by replacing the `Administration.Account` entity. + +#### User Provisioning Using a Microflow at Runtime{#microflow-at-runtime} + +If you want to use a custom user entity that is not a specialization of the `System.User` entity, you can: + +* Configure a subclass of `System.User` as the Just In Time Provisioning entity. +* Build a custom microflow (e.g., `UC_CustomProvisioning`) to create or handle your user provisioning logic based on your specific requirements. + +Select it in the **Custom UserProvisioning** field. The custom microflow name must begin with the string `UC_CustomProvisioning` and requires the following parameters: + +* **UserInfoParameter(UserCommons.UserInfoParam)**: A Mendix object containing user claims information through its associated objects. You can use this parameter to retrieve user provisioning configuration information. +* **User(System.User)**: A Mendix object representing the user to be provisioned. Ensure that the selected microflow matches this parameter signature. + +The custom microflow will be executed after the user is created or updated. + +### User Provisioning at Deploy-time{#custom-provisioning-dep} + +You can also set up custom user provisioning by setting constants when you deploy your app. This has the following limitations compared to setting up provisioning using a microflow or changing the settings at runtime: + +* You need to restart your app to apply changes to the constants +* You cannot set custom mapping of IdP claims to attributes of your custom user entity + +You can set up custom user provisioning by setting the following constants. You can set default values when you build your app but can override these in the app's environment. + +| Constant | Use | Notes | Example | +| --- | --- | --- | --- | +| CustomUserEntity | a custom user entity | in the form `modulename.entityname` – a specialization of `System.User` | `Administration.Account` | +| PrincipalEntityAttribute | the attribute holding the unique identifier of an authenticated user | | `Name` | +| PrincipalIdPAttribute | the IdP claim which is the unique identifier of an authenticated user | | `sub` | +| AllowcreateUsers | allows to create users in the application | *optional* | `True` | +| Userrole | the role that will be assigned to newly created users | *optional* - Default Userrole is assigned only at user creation
- User updates do not change the default role
- No bulk update for existing users when the default userrole changes | `User` | +| UserType | assigns usertype to the created user | *optional* | `Internal` | +| CustomUserProvisioning | a custom microflow to use for user provisioning | *optional* – in the form `modulename.microflowname` – the microflow name must begin with the string `UC_CustomProvisioning` | `Mymodule.UC_CustomProvisioning` | + +## Configuring User Provisioning for Version 2.4.0 and Below + +The section below shows the methods to configure user provisioning when using OIDC module version 2.4.0 or below. + +### Default User Provisioning + +By default, the `CUSTOM_UserProvisioning` microflow in the **USE_ME** > **1. Configuration** folder of the OIDC module uses the `OIDC_CustomUserParsing_Standard` microflow. This applies to the following mapping: + +| ID-token Provided by your IdP | Attribute of `Administration.Account` Object | +| ----------------------------- | ----------------------------- | +| sub | Name | +| name | Fullname | +| email | Email | + +{{% alert color="warning" %}} +Do not change the `UserProvisioning_StandardOIDC` microflow. This may cause problems if you upgrade to a newer version of the OIDC SSO module. Apply customizations to the `CUSTOM_UserProvisioning` microflow only. +{{% /alert %}} + +### User Provisioning Using a Microflow{#custom-provisioning-mf} + +{{% alert color="warning" %}} +Since this feature is deprecated from version 3.0.0 of the module, you can do the custom user provisioning at runtime or deploy-time. For more information, see the [User Provisioning at Runtime](#custom-provisioning-rt) and [User Provisioning at Deploy-time](#custom-provisioning-dep) sections above. +{{% /alert %}} + +Review the microflow `CUSTOM_UserProvisioning` in the **USE_ME** > **1. Configuration** folder of the OIDC module. This is where you can change the way that end-users are provisioned in your app. The OpenID token is passed to the microflow as a parameter. Use this object to find an existing, or create a new, `System.User` object for the end-user. This is set as the return value of the microflow. You can find examples included in the **USE_ME** > **1. Configuration** > **User Provisioning Examples** folder. + +Make a single call from `CUSTOM_UserProvisioning` to your own module where you implement the provisioning flow you need. This way, it will be easy to install new versions of the OIDC SSO module over time without overwriting your custom provisioning. + +The OIDC SSO module supports multiple IdPs. Since each provider can provide user data in a different format, you may want to use multiple provisioning flows. See the microflow `UserProvisioning_Sample` for an example and details on how to do this. + +## Evaluating Multiple User Matches + +Review the custom microflow `evaluateMultipleUserMatches` in the **USE_ME** folder. The module tries to find the user corresponding to the given username. This microflow is triggered when multiple matching `System.User` records are found. + +You can customize this microflow to determine the correct user. The resulting user instance will be signed in to the application and passed on to any other microflow. However, Mendix recommends using the provided unique entity attribute only. For example, `System.User.Name`. + +## User Identifiers in the OIDC and SCIM Protocols + +This section provides an overview and general guidance on User Identifiers, essential for understanding how they function in the OIDC and SCIM protocols. It is particularly relevant for Entra ID customers to ensure proper implementation and alignment of User Identifiers. + +### Overview of User Identifier + +When using OIDC SSO with Entra ID, user identifiers need to be configured correctly to ensure forward compatibility, especially if you plan to introduce the SCIM module in your application. If you are using OIDC SSO with Entra ID, you can refer to the [Microsoft documentation on attribute mapping](https://learn.microsoft.com/en-us/entra/identity/app-provisioning/customize-application-attributes). + +Entra ID uses two immutable identifiers for a user: + +* The user’s object ID: The user's object ID uniquely identifies a user, making it ideal for crosslinking users across different applications. For example, B2E applications used across the company can use the object ID as a unique identifier. +* The user’s pairwise unique identifier: It is also known as a locally unique identifier and is derived from the combination of the user's object ID and the application's identifier. This means it cannot be used to crosslink a user across different applications. For example, applications that need additional privacy can use locally unique identifiers to avoid cross-linking of users. + +Role of user identifiers in OIDC and SCIM protocols: + +* OIDC protocol can use both types of identifiers based on the use case: + + * The ID token contains a `sub` claim, which includes the pairwise unique identifier (locally unique identifier). + * The ID token also contains an `oid` claim, which includes the user’s object ID. + +* SCIM: + + * In the SCIM protocol, you typically want to use the object ID to identify a user. It is used as the value for the `externalID` claim in SCIM payloads by default. + +### Guidance on User Identifier{#guidance-user-identifier} + +The default behavior for the OIDC SSO module is to persist the value of the `sub` claim in the system.user.name attribute. This is not forward-compatible with the introduction of SCIM. Therefore, for B2E applications connected with Entra ID for SSO, Mendix recommends the following: + +* For any new application, use the `oid` claim as a user identifier by modifying the user provisioning flow. This will allow you to introduce SCIM. +* For existing applications that do not persist user-specific application data (other than system.user or administration.account), modify the user provisioning flow to use the `oid` claim instead of the `sub` claim. Delete all system.user and administration.account records to remove old user data. This will re-provision the users, allowing you to introduce SCIM. +* For existing applications that do not need to use SCIM, you can continue to use the default `sub` claim value or any other claim such as `preferred_username`. +* For existing applications where you want to introduce SCIM, you need to define a migration strategy for the identifiers. + +### Configuring `oid` Claim in the OIDC SSO + +By default, the `WellKnownendpoint` (Automatic configuration URL) does not include the `oid` claim in its metadata. You will need to manually configure the `oid` claim in the **UserProvisioning** tab of the OIDC SSO configuration using the steps below: + +1. Go to **Attribute Mapping** and click **New**. +2. Select **Search** and click **New**. +3. Create `oid` claim and map it to the Entity Attribute. + +## Read More + +* [OIDC SSO](/appstore/modules/oidc/) diff --git a/content/en/docs/appstore/use-content/platform-supported-content/modules/scim.md b/content/en/docs/appstore/use-content/platform-supported-content/modules/scim.md index 41b826dfce5..35267cbd667 100644 --- a/content/en/docs/appstore/use-content/platform-supported-content/modules/scim.md +++ b/content/en/docs/appstore/use-content/platform-supported-content/modules/scim.md @@ -50,7 +50,7 @@ The SCIM module also has the following features: * It has been tested in combination with SAML and OIDC SSO modules using Entra ID and Okta as an IdP. {{% alert color="info" %}} -If you are using the SCIM module in combination with Entra ID and OIDC SSO, you need to choose the correct attribute mapping. For more information, see the [Guidance on User Identifier](/appstore/modules/oidc/#guidance-user-identifier) section of the *OIDC SSO* and [Attribute Mapping](#attribute-mapping) section below. +If you are using the SCIM module in combination with Entra ID and OIDC SSO, you need to choose the correct attribute mapping. For more information, see the [Guidance on User Identifier](/appstore/modules/oidc/oidc-user-provisioning/#guidance-user-identifier) section of the *OIDC SSO User Provisioning* and [Attribute Mapping](#attribute-mapping) section below. {{% /alert %}} * Your IdP allows the selection of users that sync with your Mendix app, meaning your IdP controls which users are created and active in your app. @@ -183,7 +183,7 @@ For reference, the table below gives an overview of attribute mapping when using | active| Active | true | true | {{% alert color="info" %}} - In the SCIM protocol, you can configure the `object ID` to identify a user for Microsoft. It is used as the value for the `externalID` claim in SCIM payloads by default. That means, use the `oid` claim as user identifier to introduce SCIM. For more information, see the [Guidance on User Identifier](/appstore/modules/oidc/#guidance-user-identifier) section of the *OIDC SSO*. + In the SCIM protocol, you can configure the `object ID` to identify a user for Microsoft. It is used as the value for the `externalID` claim in SCIM payloads by default. That means, use the `oid` claim as user identifier to introduce SCIM. For more information, see the [Guidance on User Identifier](/appstore/modules/oidc/oidc-user-provisioning/#guidance-user-identifier) section of the *OIDC SSO User Provisioning*. {{% /alert %}} You can configure the `objectId` in SCIM using the steps below: diff --git a/content/en/docs/appstore/use-content/platform-supported-content/services/oidc-provider.md b/content/en/docs/appstore/use-content/platform-supported-content/services/oidc-provider.md index 63682ec72a9..3193f69c02f 100644 --- a/content/en/docs/appstore/use-content/platform-supported-content/services/oidc-provider.md +++ b/content/en/docs/appstore/use-content/platform-supported-content/services/oidc-provider.md @@ -310,7 +310,7 @@ This section applies only when your client is using the authorization code grant Choose one of the two options, below. -Whichever option you choose, you will need to use [Custom User Provisioning](/appstore/modules/oidc/#custom-provisioning) in the OIDC SSO module of your client app to assign the correct user roles to the end-user. +Whichever option you choose, you will need to use [OIDC SSO User Provisioning](/appstore/modules/oidc/oidc-user-provisioning/) in the OIDC SSO module of your client app to assign the correct user roles to the end-user. ##### Configuration of the OIDC Provider for Centralized Authorization with Scopes{#configure-scopes} diff --git a/static/attachments/appstore/platform-supported-content/modules/oidc/client-credential-grant.png b/static/attachments/appstore/platform-supported-content/modules/oidc/client-credential-grant.png new file mode 100644 index 00000000000..493d393bfdd Binary files /dev/null and b/static/attachments/appstore/platform-supported-content/modules/oidc/client-credential-grant.png differ diff --git a/static/attachments/appstore/platform-supported-content/modules/oidc/default_provisioning.png b/static/attachments/appstore/platform-supported-content/modules/oidc/default_provisioning.png new file mode 100644 index 00000000000..0e9c264d7b6 Binary files /dev/null and b/static/attachments/appstore/platform-supported-content/modules/oidc/default_provisioning.png differ diff --git a/static/attachments/appstore/platform-supported-content/modules/oidc/runtime-config.png b/static/attachments/appstore/platform-supported-content/modules/oidc/runtime-config.png new file mode 100644 index 00000000000..3cdd84b52b6 Binary files /dev/null and b/static/attachments/appstore/platform-supported-content/modules/oidc/runtime-config.png differ diff --git a/static/attachments/appstore/platform-supported-content/modules/oidc/user commons.png b/static/attachments/appstore/platform-supported-content/modules/oidc/user commons.png deleted file mode 100644 index 50de60449ff..00000000000 Binary files a/static/attachments/appstore/platform-supported-content/modules/oidc/user commons.png and /dev/null differ