With the auto_membership flag set on a group, users created will automatically be set as member of this group when created.
This is particularly useful for SSO enrollment, where users are created on demand automatically.
This mechanics has a significant drawback when it comes to "system" users, i.e. users set as authors of knowledge when ingesting data through connectors or feeds.
If your strategy is to give auto_membership on an administrator group, with BYPASS capabilities and / or a confidence level of 100, then you might be creating "System" users with inadequat privileges.
In these conditions, you could end up starting an ingestion feed with a user with a confidence of 100, effectively overwriting everything already on the platform. It will also set naturally the new data as having a confidence of 100, preventing any other data source to make change.
The consequences could be dire.
Solution
We envision a two-fold solution:
add a flag in user model to differentiate "system" users from the rest of flock
add the capacity to set a group as auto_membership_users and/or auto_membership_systems to differentiate the default group for new users depending on the case
Description
With the
auto_membershipflag set on a group, users created will automatically be set as member of this group when created. This is particularly useful for SSO enrollment, where users are created on demand automatically.This mechanics has a significant drawback when it comes to "system" users, i.e. users set as authors of knowledge when ingesting data through connectors or feeds.
If your strategy is to give
auto_membershipon an administrator group, with BYPASS capabilities and / or a confidence level of 100, then you might be creating "System" users with inadequat privileges.In these conditions, you could end up starting an ingestion feed with a user with a confidence of 100, effectively overwriting everything already on the platform. It will also set naturally the new data as having a confidence of 100, preventing any other data source to make change. The consequences could be dire.
Solution
We envision a two-fold solution:
auto_membership_usersand/orauto_membership_systemsto differentiate the default group for new users depending on the case