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.
2 participants
No description provided.