In a role-based access control (RBAC) administration system user is assigned certain actions and a set of scopes where these actions are applicable. For example, an administrator of a Finance department should only see members of that department, but not Sales. The classic access check approach assumes that the user can request any data and then will be validated either at the resources level (e.g., discretionary access control list (DACL) model) or in a RBAC gatekeeper module. In the case where the number of objects outside the user scope is very large and permissions are very granular, however, this approach does not scale well, thereby impacting performance overhead when processing read and write scopes.
Another problem is the proliferation of scope definitions. For example, if there is a need to grant each manager the ability to change the title for their reports, individual scopes would need to be created and assigned for each manager. In the classic ACL (access control list) model, this means that a specific ACE (access control element) is stamped with the manager's security identification (SID) onto each of the manager report objects and keeps this configuration in synchronism with the actual list of reports. This adds complexity to the permission model as well, such as when a manager changes, for example, the ACEs on each of the employees that reported to the previous manager need to be updated to the new manager.