O modelo tradicional de autorização de acesso usado em muitos sistemas é baseado em objetos e listas que controlam o acesso a estes objetos (ACLs). Resumidamente, cada objeto (por exemplo, um arquivo ou diretório no sistema de arquivos) tem uma lista associada a ele que lhe concede certos tipos de permissão (ler, alterar, excluir) para usuários ou grupos de usuário reconhecidos pelo sistema. Neste modelo, o administrador precisa "traduzir" a política de autorização da organização para as permissões (ACLs) que se pode atribuir aos objetos. Esse modelo é perfeitamente aceitável na maioria das circunstâncias. Porém, certas aplicações contêm regras de negócio que requerem um modelo de autorização mais complexo.
Nesse caso, uma alternativa para o controle de acesso é o modelo RBAC (role-based access control), cuja ideia é a concessão de permissões na aplicação com base nos papéis exercidos pelos usuários ou grupos de usuários na organização. Dessa forma, um papel no modelo RBAC é geralmente associado a uma função ou a um cargo do mundo real (por exemplo, gerente financeiro). Portanto, o objetivo não é mais vincular ACLs a objetos, mas sim determinar o conjunto de permissões que precisam ser concedidas para que determinadas funções do mundo real sejam exercidas na aplicação por quem é responsável por tais funções. Ou seja, no modelo RBAC, as permissões que representam as funcionalidades da aplicação são designadas previamente a papéis (roles) e os usuários da aplicação (ou grupos de usuário) herdam automaticamente as permissões ao serem vinculados a esses papéis (veja abaixo).
Um problema do modelo RBAC é que as permissões atribuídas a um papel (gerente financeiro, administrador, auditor, etc.) são transferidas para os usuários vinculados ao papel sem qualquer contextualização adicional. Embora isso não seja uma limitação grave para muitas aplicações, para o sistema essa abordagem é insatisfatória, pois há situações nas quais você deseja conceder determinada permissão a um usuário apenas enquanto ele tiver certa relação com um objeto. Quando essa relação termina, a permissão não deve mais ser concedida.
Por exemplo, quando se diz que o líder de um projeto de compliance deve poder fechar o projeto, não significa que ele tenha que ter permissão para fechar qualquer projeto, mas sim aquele no qual foi alocado como líder. Fica aqui evidenciado um contexto ou uma condição adicional que deve ser verificada antes de conceder a permissão.
Dadas essas considerações, o sistema requer uma variação um pouco mais sofisticada que o modelo RBAC tradicional, que pode ser classificado como um modelo estendido de controle de acesso baseado em papéis.
Esse modelo concede permissões em privilégios do sistema diretamente através da inclusão de pessoas (ou grupos de pessoas) em perfis, que desse modo atuarão como os papéis do RBAC tradicional, no sentido ilustrado pela figura acima, pessoas (ou grupos) incluídas em perfis herdam as permissões concedidas previamente a esses perfis.
Adicionalmente, o modelo é capaz de conceder permissões condicionais a pessoas (ou grupos de pessoa) que tenham sido alocadas para desempenhar determinados papéis no sistema, como "gestor de perímetros" ou "líder de projetos". Nesses casos, a concessão da permissão será sempre condicionada a uma avaliação de contexto (permite… se…).
A figura abaixo ilustra o modelo estendido RBAC adotado no sistema. Compare-a com a figura acima, que ilustra o modelo RBAC tradicional.
O gerenciamento de permissões no sistema é bastante facilitado com esse modelo. Se o controle de acesso fosse baseado em ACLs (listas de controle de acesso), o administrador do sistema precisaria configurar as permissões para cada usuário cadastrado no sistema em cada objeto. Em ambientes que contenham muitos usuários, essa operação seria extremamente trabalhosa e propensa a erros. Já no modelo implementado no sistema, essa tarefa fica bem mais simples, pois a configuração das permissões que devem ser concedidas nos diversos privilégios (operações) do sistema para os perfis e os papéis já vem feita na instalação, bastando apenas que o administrador inclua as pessoas (ou grupos) nos diversos perfis para que as permissões sejam herdadas automaticamente. Observe que as permissões padrão concedidas aos perfis e papéis podem ser editadas a qualquer momento.