User Metering Named Identifier for SCIM, OIDC SSO, and SAML #10070
Conversation
| 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. However, starting from version 2.0.0 of the UserCommons module, this is no longer mandatory. If you have added a new microflow, you will need to refresh the module containing your microflow as described in the [Mx Model Reflection](/appstore/modules/model-reflection/). This selection can be blank if you do not want to add custom logic. | ||
|
|
||
| 4. Click **Save** to save the configuration. | ||
| 4. To improve licensing and metering accuracy, a configuration requires the use of a mandatory **User Metering Named Identifier**, for example, `email` or `sub`, etc. |
There was a problem hiding this comment.
We need to explain better:
"To facilitate future improvements in the Mendix platform's user metering capabilities, you can configure which cliam you want to map to the User Metering Named Identifier. This is specifically relevant if a multi-app user license is allocated to your application; you need to make sure that a multi-app user gets the same value for the User Metering Named Identifier in each of the apps for that user. In most cases the end user's email address is the best choice, so we've made that a default.
The platform's current user metering mechanism is using the system.user.name to count users. It is often used for technical user identifiers, e.g. the "oid" value when using OIDC SSO module. See https://docs.mendix.com/appstore/modules/oidc/#guidance-user-identifier "
There was a problem hiding this comment.
@karuna, I will confirm this messaging on monday after meeting with Job/Satyam. As i said before.
There was a problem hiding this comment.
I would want the "guidance-user-identifier" section to be updated as well.
I think it needs to include the info about the new User Metering Named Identifier as well.
There was a problem hiding this comment.
I would want the "guidance-user-identifier" section to be updated as well.
I think it needs to include the info about the new User Metering Named Identifier as well.
Hi @JaapF, based on your comment above, do you mean to update the below?
- 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.
- so, if we are using oid as an identifier then we should choose "oid" as usernamedidentifier???
- For existing applications that do not need to use SCIM, you can continue to use the default
subclaim value or any other claim such as preferred_username.
- so, if we are using oid as an identifier then we should choose "sub" as usernamedidentifier???
Please refer Guidance on User Identifier for the original section.
There was a problem hiding this comment.
Thanks for trying, but it's actually more nuanced.
I'll work on something to explain better and after that you can iterate - as always
| * To improve licensing and metering accuracy, a configuration requires the use of a mandatory **User Metering Named Identifier**, for example, `email` or `sub`, etc. | ||
|
|
||
| {{< figure src="/attachments/appstore/platform-supported-content/modules/oidc/default_provisioning.png" >}} | ||
| * In the **UserProvisioning** tab, select the identifier in the **User Metering Named Identifier** field to be used for metering (default value is `email`). |
There was a problem hiding this comment.
Same text as with SAML.
My same comment applies.
| 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. However, starting from version 2.0.0 of the UserCommons module, this is no longer mandatory. If you have added a new microflow, you need to refresh the module containing your microflow as described in the [Mx Model Reflection](/appstore/modules/model-reflection/). The selection can be blank if you do not want to add custom logic. | ||
|
|
||
| {{< figure src="/attachments/appstore/platform-supported-content/modules/scim/user_commons.png" class="no-border" >}} | ||
| * To improve licensing and metering accuracy, a configuration requires the use of a mandatory **User Metering Named Identifier**, for example, `email` or `sub`, etc. |
There was a problem hiding this comment.
Same text as with SAML.
My same comment applies.
| * **Attribute Mapping**: under **Attribute Mapping**, select an **IdP Attribute** (claim) for each piece of information you want to add to your custom user entity. Specify the **Configured Entity Attribute** where you want to store the information. | ||
|
|
||
| Note the following: | ||
| Note the following: |
There was a problem hiding this comment.
The whole section is rather cryptic to me.
It hasn;t really changed so we can either:
- pragmatic: leave it 'as is' and improve later
- use this opportunity to improve.
I'm in favor of the latter. But i would need someone to explain to me what we're trying to say in the next bullets.
| 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. However, starting from version 2.0.0 of the UserCommons module, this is no longer mandatory. If you have added a new microflow, you will need to refresh the module containing your microflow as described in the [Mx Model Reflection](/appstore/modules/model-reflection/). This selection can be blank if you do not want to add custom logic. | ||
|
|
||
| 4. Click **Save** to save the configuration. | ||
| 4. To facilitate future improvements in the user metering capabilities of the Mendix Platform, you can configure which claim you want to map to the **User Metering Named Identifier**, for example, `email` or `sub`, etc. This is particularly relevant if a multi-app user license is allocated to your application and you need to ensure that a multi-app user receives the same value for the **User Metering Named Identifier** in each of the apps for that user. |
There was a problem hiding this comment.
We should NOT suggest "sub". Instead it should preferably be a human-understandable unique user identifier like email address, employee number.
Short term fix: simply remove 'sub' as a suggestion.
There was a problem hiding this comment.
@karuna (and note to self), user metering is a sensitive topic so I alligned with Satyam (PM for user metering).
We discussed the messaging and agreed an the following sentences after careful deliberation.
"To facilitate upcoming enhancements in the platform, you need to do some configuration so mendix can correctly identify endusers.
Correct identification is crucial for ensuring consistent and accurate end-user metering and deduplication across multiple applications in your landscape
The XX-field will be used for de-duplication of users, which is relevant if you have a multi-app user license."
I'll leave another comment, where I combine this with the more technical details.
There was a problem hiding this comment.
To facilitate upcoming enhancements in the platform, you need to do some configuration so Mendix can correctly identify endusers. Correct identification is crucial for ensuring consistent and accurate end-user metering and deduplication of endusers across multiple applications in your landscape.
For this reason the UserCommons module features the User Metering Named Identifier entity in version x.y.z and higher. If you have a 'multi-app internal user' license or an 'external user' license, it's important that you persist the same value for the same enduser across different apps, regardless of which modules you use. In most cases, the end-user's email address is a good choice.
Whereas currently Mendix currently uses the system.user.name to identify users, it will use the User Metering Named Identifier instead, unless it's not populated. For accurate user metering you don't need to change what value is persisted in "system.user.name"; you can continue to persist whatever value you are using there today. The system.user.name is often used for technical user identifiers.
If you want to use a user attribute other than email address for the User Metering Named Identifier you can configure this on the UserProvisioning tab:
- select the identifier in the User Metering Named Identifier field to be used for metering
- Click Save to save the configuration.
| * In the **UserProvisioning** tab, select the identifier in the **User Metering Named Identifier** field to be used for metering (In most cases, the end user's email address is the best choice, so the default value is `email`). | ||
| * The Platform's current user metering mechanism is using the `system.user.name` to count users. It is often used for technical user identifiers, for example, the `oid` value when using the OIDC SSO module. For more information, see [Guidance on User Identifier](/appstore/modules/oidc/#guidance-user-identifier). The **User Metering Named Identifier** prioritizes the selected identifier over the default `system.user.name` for accurate user tracking. | ||
|
|
||
| {{< figure src="/attachments/appstore/platform-supported-content/modules/oidc/default-provisioning.png" >}} |
There was a problem hiding this comment.
To facilitate upcoming enhancements in the platform, you need to do some configuration so Mendix can correctly identify endusers. Correct identification is crucial for ensuring consistent and accurate end-user metering and deduplication of endusers across multiple applications in your landscape.
For this reason the UserCommons module features the User Metering Named Identifier entity in version x.y.z and higher. If you have a 'multi-app internal user' license or an 'external user' license, it's important that you persist the same value for the same enduser across different apps, regardless of which modules you use. In most cases, the end-user's email address is a good choice.
Whereas currently Mendix currently uses the system.user.name to identify users, it will use the User Metering Named Identifier instead, unless it's not populated. For accurate user metering you don't need to change what value is persisted in "system.user.name"; you can continue to persist whatever value you are using there today. The system.user.name is often used for technical user identifiers, for example, the oid value when using the OIDC SSO module. For more information, see Guidance on User Identifier.
If you want to use a user attribute other than email address for the User Metering Named Identifier you can configure this on the UserProvisioning tab:
select the identifier in the User Metering Named Identifier field to be used for metering
Click Save to save the configuration.
|
|
||
| {{< figure src="/attachments/appstore/platform-supported-content/modules/scim/user-commons.png" >}} | ||
|
|
||
| Save this configuration. Double-click on the **Alias** name and you will be able to copy the generated **API Key**. |
No description provided.