Comment 17 for bug 1658641

Thinking about this a bit more and it seems we have two different options when using the mapping purge.

1.) We can have keystone-manage mapping_purge accept an argument for a specific user ID. If that user id isn't in a specific domain backend, then it should be removed from the id_mapping table, similiar to what happens today. In addition to the path, keystone could remove the role assignment for that ID if they exist in the assignment tables.

2.) We can add another argument to the mapping_purge command that forces the removal of all assignments associated to purged identities (essentially option #1 but batch processing).

My concern for both approach is that id_mappings can be regenerated because keystone pulls the identity from the domain backend (LDAP/AD/etc...), which it treats as the source of truth. Since it's possible for users to have assignments, when we remove them, there is no recovery option if the users is enabled or recreated in the domain backend. In a way, this makes mapping_purge less idempotent because;

- user is create in ldap
- user is mapped in keystone and given an id based on a hash
- user is granted assignments to various projects
- user is disabled or moves groups in ldap
- the users id and mapping are purged in keystone, along with all of the user's assignments
- the user is enabled or moved back to the original group, the mapping backend maps the user to their previous ID
- user doesn't have any of the assignment they had prior to the purge operation

Is this going to be an issue?