O sistema de permissões de segurança é um mecanismo de autorização e autenticação de usuários. Dessa forma, é possível definir regras de acessos a usuários ou grupos de usuários, além de permitir múltiplas formas de efetuar o login no sistema, utilizando as informações contidas no Banco de Dados (padrão) ou um provedor de login externo. Os provedores de login externo suportados incluem o Active Directory, SAML, OpenID-connect, Microsoft Account, Twitter, Login social (Github, Facebook, LinkedIn, Google e Cronapp), Certificados digitais e ICP Brasil, podendo também ser personalizado para qualquer provedor de login externo compatível com OAuth 2.0.

Estrutura

A Permissão de Segurança do Cronapp possui uma estrutura dividida em 3 camadas: Permissionáveis (Securable), Grupos (Role) e Usuários (User). Essa estrutura possui uma pequena hierarquia, onde um permissionável possui as permissões do sistema e é composto por usuários e grupos de usuários; um Grupo, possui um ou mais usuários e pode estar associado a um ou mais permissionáveis e o Usuário, que pode estar dentro de um ou mais grupos e estar diretamente vinculado a um ou mais permissionáveis. A figura 1 representa essa estrutura.

Open

Permissionável

Cada permissionável possui um conjunto de permissões (métodos de requisição HTTP) que podem ser aplicadas em arquivos específicos ou todo o conteúdo dentro de um diretório. O acesso a arquivos é feito diretamente nas configurações do permissionável, porém, o Cronapp também utiliza a lista de permissionáveis do sistema para liberar acessos a recursos dentro de uma página, relatório, bloco de programação e diversas outras funcionalidades (veja exemplos no tópico Atribuir Permissões).

Por padrão, os projetos criados no Cronapp já incluem os seguintes permissionáveis: Public, Authenticated e Administrators. Não sendo possível renomear ou remover esses permissionáveis. Os permissionáveis herdam permissões de outros permissionáveis, assim:

• O permissionável Public possui as permissões mais básicas, como acesso ao conteúdo do diretório public e arquivos necessários para que os usuários não logados possam visualizar o conteúdo público, exemplo de arquivos CSS e tema da aplicação.

• O permissionável Authenticated herda todas as permissões do permissionável Public e possui algumas permissões próprias, como acesso ao conteúdo do diretório views/logged/.

• O permissionável Administrators herda todas as permissões do permissionável Authenticated e possui algumas permissões próprias, com acesso completo ao sistema e diretório views/admin/.

• Todo os novos permissionáveis do sistema herdarão automaticamente as permissões do permissionável Authenticated.

Usuários vinculados a mais de um permissionável terá o acesso do permissionável de maior abrangência. Por exemplo, se um usuário estiver associado a dois permissionáveis, através de grupos ou diretamente, sendo que o primeiro permissionável concede acesso a parte do sistema e o segundo possua acesso completo, ao logar, esse usuário terá acesso total. 

Alterar regras

É possível modificar as regras dos 3 permissionáveis padrão para que eles se adequem melhor as necessidades do seu sistema. Porém, é preciso ter bastante atenção ao fazer isso, pois podem abrir brechas para falhas de segurança. Além disso, essas alterações devem contemplar tanto a aplicação web quanto a mobile.

Em alguns casos, talvez seja prudente ter o permissionável Authenticated mais restrito, apenas com o que é realmente comum e criar permissionáveis com acessos bem específicos ao que aquele usuário ou grupo de usuários necessitarão dentro do sistema. Por exemplo, o permissionável “comprador” pode contemplar tudo o que é necessário para a funcionalidade, e se necessário, criar permissionáveis ainda mais específicos, como “Comprador - Escrita” e “Comprador - Leitura”.

Grupos

Um grupo pode conter diversos usuários, e esses usuários herdarão automaticamente os acessos dos permissionáveis dos quais esse grupo pertença. Dessa forma, um grupo é considerado um papel ou função, já que pode possuir as regras necessárias para que o usuário associado execute seu papel e acesse suas funções dentro do sistema, exemplo: Vendedor, Gerente, Gestão de pessoas.  

Por padrão, os projetos criados no Cronapp já incluem os seguintes Grupos:

• Anonymous Users: associado ao permissionável Public.

• Authenticated Users: associado ao permissionável Authenticated.

• Administrators: associado ao permissionável Administrators. É fundamental que sempre haja um grupo associado ao permissionável Administrators.

Usuários

Um usuário do sistema pode obter suas autorizações por estar associado a grupos ou diretamente a permissionáveis. Usuários criados sem vínculos com grupos ou permissionáveis receberá, de forma implícita, todas as regras do permissionável Authenticated. 

Por padrão, os projetos criados no Cronapp contêm o usuário:

• Administrator: esse usuário já vem associado ao grupo Administrators, que por sua vez, está vinculado ao permissionável Administrators. É fundamental que sempre haja um usuário associado ao permissionável Administrators.
  
  

Estrutura de Classes

Por padrão, o sistema de permissões e segurança armazena informações de usuário em um banco de dados usando o JPA. Essa abordagem funciona bem para muitos aplicativos. Entretanto, você pode preferir usar um mecanismo de persistência ou esquema de dados diferente, dessa forma, é possível alterar e tornar o modelo extensível e personalizável.

Na figura abaixo são exibidas as classes usadas na Permissão de Segurança do Cronapp. Dependendo das configurações do seu projeto, outras três classes também serão exibidas: AuditLog (Log de auditoria), Device (Dispositivos móveis) e InvalidatedToken (Invalidação de tokens) (acesse as documentações Diagrama, Log de Auditoria e Invalidação de Tokens para mais detalhes sobre essas três classes).

Open

O modelo de dados das permissões de segurança consiste dos seguintes tipos de entidade (Figura 1.1):

Relacionamentos entre entidades

Os tipos de entidade são relacionados entre si das seguintes formas:

• Cada User pode ter múltiplos Securables associados, e cada Securable pode estar associado a múltiplos Users. Esse relacionamento muitos-para-muitos é representado pela entidade UserSecurable.

• Cada User pode ter múltiplos Logins associados.

• Cada User pode ter múltiplos Roles associados, e cada Role pode estar associada a múltiplos Users. Esse relacionamento muitos-para-muitos é representado pela entidade UserRole.

• Cada Role pode ter múltiplos Securables associados, e cada Securable pode estar associado a múltiplos Roles. Esse relacionamento muitos-para-muitos é representado pela entidade RoleSecurable.

• Cada Securable pode ter múltiplos Views associados.

Relacionamentos para Multi Aplicações

Os relacionamentos abaixo são específicos para a utilização de Multiplas aplicações dentro da mesma base de dados, para isso são utilizadas as tabelas Application e ApplicationUser. Os tipos de entidade são relacionados entre si das seguintes formas:

• Cada Application pode ter múltiplos Role associados.

• Cada Application pode ter múltiplos Securable associados.

• Cada Application pode ter múltiplos View associados.

• Cada Application pode ter múltiplos User associados, e cada User pode estar associado a múltiplos Application. Esse relacionamento muitos-para-muitos é representado pela entidade ApplicationUser.

Tabelas

Abaixo são detalhados todos os campos das tabelas usadas pelo Sistema de Segurança. 

User

Usuário.

Role

Grupo.

Login

A entidade Login garante que um mesmo usuário possa logar com diferentes contas. Por exemplo, um usuário pode logar e acessar na sua conta do sistema usando sua conta do Facebook, Gmail ou do próprio sistema, essa última é gravada diretamente na tabela User.

Securable

Permissionável.

View

Aplica o controle de acesso (métodos de requisição HTTP) à diretórios e arquivos.

Application

Aplicações. Ver mais detalhes em Multi aplicações.

Role Securable

Tabela de relacionamento entre Grupo e Permissionável.

User Securable

Tabela de relacionamento entre Usuário e Permissionável.