Controle do acesso aos dados

No que diz respeito à segurança da aplicação, os conceitos de autenticação e autorização desempenham um papel crucial.

Assista ao vídeo para obter uma síntese da autenticação e autorização.

Ainda não configuramos nenhuma autorização em nosso aplicativo. Isso significa que atualmente não existem restrições e que todas as solicitações ainda têm acesso total a toda a aplicação. Nesta lição, aprenderemos a restringir o acesso à aplicação.

Em um ambiente produtivo, todos os pontos de acesso são autenticados por padrão, mesmo que não estejam configuradas restrições. O método de autenticação é livremente personalizável. Por conveniência, um conjunto de métodos de autenticação é suportado para uso imediato para cobrir os cenários mais comuns. Caso seja necessário, por motivos empresariais, expor pontos de acesso abertos a usuários anônimos, devem ser tomadas medidas adicionais. A configuração da autenticação para o ambiente de produção não é abordada neste curso.

Como já vimos, nenhuma autenticação é necessária ao testar o aplicativo no ambiente de desenvolvimento. Veremos mais tarde como configurar a autenticação para o ambiente de teste.

A seguir, exploraremos as anotações que você pode usar para controlar o acesso a dados empresariais em um nível refinado. Você pode inserir as anotações discutidas diretamente nos arquivos .cds nos quais os serviços são definidos. No nosso caso, este seria o arquivo cat-service.cds para o CatalogService e o arquivo admin-service.cds para o AdminService.

No entanto, a melhor prática é armazenar as anotações de autorização em diferentes arquivos .cds para separá-las da definição de serviço real. Isso mantém as definições de serviço reais concisas e focadas apenas na estrutura. Ele também permite que você dê a modelos de autorização propriedade e ciclo de vida separados.

Vamos seguir esta melhor prática e criar arquivos .cds separados para modelar as regras de acesso para o CatalogService e o AdminService. Chamamos esses arquivos de cat-service-auth.cds e admin-service-auth.cds respectivamente e os salvamos na pasta srv do nosso projeto, assim como os arquivos com as definições de serviço.

Primeiro, vamos dar uma olhada no arquivo cat-service-auth.cds, que usamos para controlar o acesso ao CatalogService (consulte a figura a seguir).

Neste arquivo, importamos as definições das entidades Autores e Livros, bem como a definição da ação submitOrder do modelo CatalogService por meio da diretriz using .

Os Autores e a entidade Livros são anotados com @readonly através da diretiva annotate , a fim de restringir o acesso de todos os usuários ao acesso somente leitura.

Como base para o controle de acesso, você pode projetar funções conceituais específicas da aplicação. Os usuários podem ter várias funções atribuídas por um usuário administrativo na solução de administração de autorizações da plataforma.

Além das funções de usuário específicas da aplicação, o CAP também suporta algumas pseudofunções predefinidas, como authenticated-user. Esta função se refere a usuários que foram autenticados com êxito.

No exemplo mostrado, a anotação @requires é usada para controlar que somente usuários autenticados podem executar a ação submitOrder.

Em seguida, vejamos o arquivo admin-service-auth.cds, que contém o controle de acesso para o AdminService (consulte a figura a seguir).

Aqui, também, empregamos primeiro a diretiva using para importar as definições a serem anotadas (Authors and Books Entity) do modelo AdminService.

A entidade Autores é anotada com @(requires: 'admin'). Isso determina que somente os usuários que têm a função de administrador específica do aplicativo podem acessar a entidade Autores.

Para definir autorizações para a entidade Livros, é usada a anotação @restrict . Ele especifica que somente os usuários com a função de administrador específica do aplicativo podem executar operações de LEITURA, CRIAÇÃO e ATUALIZAÇÃO na entidade Livros. As operações DELETE também são permitidas apenas para usuários com a função de administrador, com a restrição adicional de que somente livros com estoque igual a 0 podem ser excluídos.

A anotação @Restrict fornece uma matriz com qualquer número de objetos de privilégio, em que cada objeto de privilégio tem a seguinte estrutura:

1
{ grant: <events>, to: <roles>, where: <filter-condition> }

As características do objeto de autorização são definidas da seguinte forma:

• grant

  um ou mais eventos (como LEITURA, CRIAR, ATUALIZAR e EXCLUIR) aos quais o privilégio se aplica

• to

  uma ou mais funções de usuário ou pseudofunções às quais a autorização se aplica (opcional)

• where

  uma condição de filtro que restringe mais o acesso em um nível de instância (opcional)

Uma solicitação passa por uma restrição que consiste em uma variedade de privilégios se pelo menos um dos privilégios for cumprido.

Agora que vimos como definir autorizações com a ajuda de anotações, queremos ver a autenticação a seguir. A autenticação com êxito de um usuário constitui a base para poder executar verificações de autorização.

A CAP é fornecida com uma série de estratégias de autenticação pré-construídas.

Na produção, a estratégia de autenticação jwt é utilizada por padrão. A identidade do usuário, bem como as funções e os atributos de usuário atribuídos, são fornecidos no momento da execução por uma instância vinculada do serviço User Account and Authentication (UAA). Isso é feito na forma de um token JWT no cabeçalho Authorization de solicitações HTTP de entrada.

Durante o desenvolvimento, a estratégia de autenticação mocked é utilizada por padrão. Essa estratégia de autenticação utiliza autenticação padrão com usuários fictícios predefinidos. Opcionalmente, você pode definir usuários adicionais por meio do arquivo package.json, como mostrado na seguinte figura:

1
cds env get requires.auth

A autenticação mocked utiliza autenticação padrão. Por isso, você pode utilizar o cabeçalho Authorization com o esquema de autenticação Basic em suas solicitações para fins de teste. As credenciais são especificadas no formulário <user>:<password>, como mostrado no seguinte exemplo:

12
GET <service_url>/Books
Authorization: Basic catuser:abcd1234

Assista ao vídeo para ver como adicionar restrições ao modelo CDS.