Idea ID: 2822112

Use multiple threads to process role assignment recalculations during the removal of child roles

Status : Under Consideration
Under Consideration
See status update history
10 months ago

When a child role is removed from a parent, the RRSD processes the event with a single thread and blocks all other events in the queue. When the parent has a lot of user assignments this will take a considerable time to complete as the recalculations for each user are done in series.

These recalculations seem to be independent of each other and should be good candidates for multi-threading. This would reduce the time it takes to process the event.


Role Based Provisioning
  • This customer is our only pure Windows customer and even MF says there should not be any difference, I see there is. In number of bugs in eDir, in the performance and stability. 

    The second factor might be of using one "dynamic" resource and entitlements are mapped to the role from this one resource. 

    Third factor might be dynamic groups? This customer does all business role assignments over dynamic groups.

    MF engineers already looked at it and they just said that they cannot do anything. We have to wait. 

    Meantime, I just updated RRSD in our test environment because we are before the IDM upgrade in PRD. The new driver speeds up the role removal drastically. At least, the process is running in a different thread and the driver is ready to process new events. At least, it seems to be like that. 

  • The latest version of the Roles and resource driver does have an option to turn multithreading for recalculating the assignments, but it is only supported in 48. However if it is taking 40 minutes per user I am not sure that is the whole problem. We have round about 500 roles assignments per user and it takes less than a minute per user. And it is only when there are thousands of users assigned to the role we have an issue but even then it is usually over in an hour.
  • We've been facing now to the same situation. A customer is using dynamic groups to assign business roles and they made a mistake and one business role was assigned to all users. It was quite fast because I configured multi-threading (I also changed policies to use regex and this allow me to differentiate users based on the CN and OU). Anyway, next day the customer removed the assignment/fixed the dynamic group and all users are loosing the roles now. (the business role had 250 permission roles assigned). And this operation is provided by one thread only and it is a main thread. Because the customer has thousands of roles and resources, the role removal takes 45 minutes for one user!!! It's been removing the roles from last Thursday and we are maybe in 1/3 of the process. Of course, this was escalated to MF. It is ridiculous to wait approximately 10 days for removal one business role from ±800 users...

    It is quite strange to me that this has not been solved yet in IDM. Don't MF IDM customers use roles or what? And I do not think it is hard to implement. The users are independent objects in the system, so it cannot be an issue to run removal in parallel for every user.

  • Under consideration for an upcoming release. We will need to evaluate efforts.

  • Yes, the multithreading  for individual assignments works well, but when we remove a child role from a parent role the event does not start processing  until the DirXML-DriverStorage attribute is empty and  no other events will be processed until it is finished. During the processing the thread recalculates the role assignments for each of the accounts which are assigned to the parent role one after the other. These recalculations seem to independent of each other which could make them good candidates for multithreading. The recalculations happen at a point in the RRSD after the policies are processed and the event does not get added to DirXML-DriverStorage even when multithreading is enabled.  The recalculations are expensive  for example if the recalculation takes .3 of a second and there are 8000 associations  it will hold up the queue for 40minutes. But if there were more threads working on the calculations it would take a fraction of the time.