Description

Background:
On Wednesday, February 7 RBAC ran its weekly principal cleanup job for its tenants. This job reaches out to the Back Office Proxy (BOP) which reaches out to IT to see if each user is still relevant. If there is data for a user, RBAC does nothing, however if there is a 200 response from BOP and no data for a specific user, RBAC will delete the user from its database, which ultimately deletes its group relations resulting in the user having no permissions. 

The job that ran on February 7th deleted principals that were still valid which resulted in users being removed from groups/ having no permissions. Since these users were removed, when they reached back out to RBAC, they were recreated under a different ID and treated as new users. 

To resolve the issue, we are going to disable the principal deletion portion of the principal cleanup job, and add additional logs on the response that is returned from BOP. We are also going to investigate either tying in to the IT UMB for user deletion or updating our job to say that the principal needs to not be present in IT for X amount of weeks before we remove it from RBAC. 

Open Questions:

• Should we move to the IT UMB or add additional safety checks to our cleanup job? 

Follow-ups (sub-tasks):

• Disable the principal deletion portion of the cleanup task but still log the users eligible for deletion
• Add additional logs to log the response from BOP 
• Investigate adding safety checks to our cleanup job (principal must be gone for X amount of weeks before deletion) or moving to IT UMB