Autorização via controle de acesso

Autorização é o processo de conceder acesso às diferentes partes e recursos da aplicação web aos usuários. Uma forma comum de autorizar usuários é por meio do controle de acesso, em que o administrador do site define quais permissões devem ser concedidas aos usuários e outras entidades para acessar determinados recursos.

Autorização não deve ser confundida com autenticação, que é o processo de validar que o usuário é quem afirma ser, geralmente realizado fornecendo credenciais de conta. Uma vez que o usuário está autenticado, o processo de autorização ainda deve ser executado em cada requisição, para garantir que o usuário tenha acesso ao recurso solicitado.

Ao acessar a aplicação via GraphQL, precisamos validar se o usuário tem acesso aos elementos solicitados do schema. A lógica de autorização deve ser codificada dentro da camada GraphQL?

A resposta é não. Como a documentação em graphql.org deixa claro, a lógica de autorização pertence à camada de lógica de negócio, e é de lá que é acessada pelo GraphQL. Dessa forma, a aplicação pode ter uma única fonte de verdade para autorização (ou seja, a oferecida pelo WordPress):

O Gato GraphQL respeita esse princípio, refletindo (e, sob o motor, delegando a) o mecanismo de autorização fornecido pelo WordPress.

​

Políticas de Controle de Acesso

Entre as diversas políticas de controle de acesso que podemos implementar para nossa aplicação, as duas mais populares são o Controle de Acesso Baseado em Papéis (RBAC) e o Controle de Acesso Baseado em Atributos (ABAC).

O WordPress, e o Gato GraphQL, suportam ambos.

Com o Controle de Acesso Baseado em Papéis concedemos permissões com base em papéis e, em seguida, atribuímos os papéis aos usuários. Por exemplo, o WordPress possui um papel administrator com acesso a todos os recursos, e os papéis editor, author, contributor e subscriber com permissões restritas em graus variados, como poder criar e publicar um post no blog, apenas criá-lo, ou apenas lê-lo.

Com o Controle de Acesso Baseado em Atributos, as permissões são concedidas com base em metadados que podem ser atribuídos a diferentes entidades, incluindo usuários, recursos e condições do ambiente (como o horário do dia ou o IP do visitante). Por exemplo, no WordPress, a capability edit_others_posts é usada para validar se o usuário pode editar posts de outros usuários.

Em termos gerais, o ABAC é preferível ao RBAC porque nos permite configurar permissões com controle granular, e a permissão é inequívoca em seu objetivo.

Por exemplo, no WordPress, o papel editor possui a capability edit_others_posts, mas podemos querer permitir que uma pessoa com o papel author edite o post de outro autor, sem no entanto conceder a ela o conjunto completo de permissões que são concedidas a um editor (como também excluir posts de outros autores). Portanto, conceder a capability edit_others_posts e verificar essa condição é mais adequado do que verificar o papel editor.

​

Definindo a Visibilidade

Quando o usuário não possui permissão para acessar o campo solicitado do schema GraphQL, qual deve ser o erro retornado?

Há duas possibilidades, em conformidade com a visibilidade desejada para o schema: pública ou privada.

Para o schema público, o schema GraphQL exposto é o mesmo para todos os usuários, e cada campo descreve quais permissões são necessárias para acessá-lo. Ao solicitar um campo inacessível, a mensagem de erro explicará por que o acesso não foi concedido ao usuário.

Para o schema privado, o schema GraphQL é personalizado para cada usuário, e apenas os campos que ele/ela pode acessar serão expostos. Ao solicitar um campo inacessível, a mensagem de erro informará que o campo não existe.

​

Controle de Acesso via Interface do Usuário

No Gato GraphQL, as regras de controle de acesso são injetadas no schema em tempo de execução, como configuração definida pelo usuário via access control lists. Dessa forma, a camada GraphQL refletirá imediatamente as mudanças na política de controle de acesso, sem necessidade de atualizar nenhum código ou recompilar o schema:

O administrador do site configura a ACL, selecionando:

• Os campos a validar
• Uma regra a validar, entre:
  • o usuário deve estar logado?
  • o usuário deve estar deslogado?
  • o usuário deve ter um determinado papel?
  • o usuário deve ter uma determinada capability?
• A configuração específica da regra:
  • quais papéis?
  • quais capabilities?
• A visibilidade:
  • padrão (ou seja, a mesma atribuída ao schema)?
  • pública?
  • privada?