Você pode controlar o acesso de algumas maneiras. O RBAC é segurança baseada em funções. Grupos são grupos de usuários e funções são grupos de direitos de acesso. Você pode mapear grupos em funções ou usuários em funções. Nesse caso, suas regras de acesso podem ser assim:
"Permitir que todos no RH vejam o banco de dados de RH", o que, na implementação, faria com que os usuários agrupassem em um objeto LDAP groupOfUniqueNames. Isso geralmente leva a uma organização mais limpa e a maioria das organizações tem como objetivo o RBAC quando começar do nada. Se o RBAC é refinado é outra questão. Por exemplo, as funções controlam o acesso a um documento inteiro com base em grupos, mas não discriminam o nível do parágrafo para você. Para algumas organizações, isso é grosseiro.
Uma abordagem mais simples, se isso soar muito complicado, é fazer o ABAC (segurança baseada em atributos), onde seu aplicativo / camada intermediária / o que quer que esteja controlando o acesso por consultas LDAP que se parecem com isso: "Se você tem um atributo 'foo', você pode clicar no aplicativo foo." ou "Se seu atributo foo tiver o valor HR, você poderá acessar o aplicativo HR."
O problema com o ABAC é que ele se transforma em uma verdadeira bagunça. Mas para algumas coisas é uma verificação fácil. Por exemplo, talvez eu queira que pessoas com uid, userPassword e mail sejam permitidas em uma webapp, porque esses são os atributos obrigatórios que meu aplicativo precisa. Daí, meu aplicativo pode procurar papéis e tomar decisões mais refinadas. Login e nologin são realmente as consultas (login=*) and (!(login=*)) que permitiriam o acesso com base na existência de um único atributo. Isso é ABAC e geralmente não é reutilizável e / ou cenários de ponta matam o design. Como um exemplo planejado, e se eu tiver um login no sistema para um trabalho agendado, mas realmente não quero que a conta do sistema faça login no meu aplicativo. Se eu definir nologin (como shell para / dev / null ou similar), então meu trabalho cron não é executado, se eu configurá-lo para login, meu trabalho cron é executado, mas agora uma conta do sistema tem a capacidade de entrar no meu aplicativo desnecessariamente. Crie duas funções (chame-as de usuários e contas do sistema, etc.) e crie uma política que atenda aos dois requisitos.
Em uma escala corporativa, as organizações usam produtos de gerenciamento de identidades (IDM) para gerenciar, reportar e automatizar centralmente essas políticas de acesso. A automação e a geração de relatórios são úteis quando você tem N sistemas em N suborganizações em uma grande empresa / organização.