Presently managed/user records have a "roles" property which is used for tracking two different types of roles associated with the user: provisioning roles (which come from managed/role) and openidm- specific authorization roles (openidm-admin, openidm-authorized, etc...).
Tracking both of these types of roles in a single field causes many problems. One is that the UI for managing users needs to be aware of this dual-use; since this is a special-case for managed/users, that logic must be hard-coded within the UI (rather than driven by schema configuration). Another problem is that the managed/role entries are included within the "roles" attribute for the security context; as there gets to be a large number of these assigned to a user, that user may start to experience problems with serializing their context or generating a JWT that fits within the maximum size of a cookie (4kb).
The answer to this problem is to simply break up this property, so that the provisioning roles are stored separately from the authz roles. For example:
Note that with these separated like this, the value within "roles" need not contain the full path to the resource ("managed/role/1231234"). This is not necessary since there is no need to distinguish different types within the field. Instead, the meaning of the values can be established by referring to the schema definition in conf/managed.json:
Finally, note that this schema refers to "repo/internal/role" - this is not an object that exists at the moment; presently there is no definitive list of openidm- authorization roles. To make this field operate consistently with the managed/role type, having an actual resource to look up will be required.