Control del acceso a los datos

Con respecto a la seguridad de la aplicación, los conceptos de autenticación y autorización desempeñan un papel crucial.

Vea el vídeo para obtener un resumen de la autenticación y la autorización.

Aún no hemos configurado ninguna autorización en nuestra aplicación. Esto significa que actualmente no hay restricciones y todas las solicitudes aún tienen acceso completo a toda la aplicación. En esta lección, aprenderemos a restringir el acceso a la aplicación.

En un entorno productivo, todos los puntos finales se autentican de forma predeterminada, incluso si no se configuran restricciones. El método de autenticación se puede personalizar libremente. Por conveniencia, se admite un conjunto de métodos de autenticación listos para usar para cubrir la mayoría de los escenarios comunes. En caso de que sea necesario por motivos empresariales exponer puntos finales abiertos a usuarios anónimos, se deben tomar medidas adicionales. La configuración de la autenticación para el entorno de producción no se trata en este curso.

Como ya hemos visto, no se requiere autenticación al probar la aplicación en el entorno de desarrollo. Más adelante veremos cómo configurar la autenticación para el entorno de prueba.

A continuación, exploraremos las anotaciones que puede utilizar para controlar el acceso a los datos empresariales a un nivel detallado. Puede insertar las anotaciones analizadas directamente en los archivos .cds en los que se definen los servicios. En nuestro caso, este sería el archivo cat-service.cds para CatalogService y el archivo admin-service.cds para el AdminService.

Sin embargo, es una práctica recomendada almacenar las anotaciones de autorización en diferentes archivos .cds para separarlas de la definición de servicio real. Esto mantiene las definiciones de servicio reales concisas y centradas solo en la estructura. También le permite otorgar a los modelos de autorización una propiedad y un ciclo de vida separados.

Seguiremos esta práctica recomendada y crearemos archivos .cds separados para modelar las reglas de acceso para CatalogService y AdminService. Llamamos a estos archivos cat-service-auth.cds y admin-service-auth.cds respectivamente y los guardamos en la carpeta srv de nuestro proyecto, al igual que los archivos con las definiciones de servicio.

Primero, echemos un vistazo al archivo cat-service-auth.cds, que utilizamos para controlar el acceso al CatalogService (véase la siguiente figura).

En este archivo, importamos las definiciones de las entidades Autores y Libros, así como la definición de la acción de envío de pedidos desde el modelo CatalogService a través de la directiva using .

Los autores y la entidad Libros se anotan con @readonly a través de la directiva annotate con el fin de restringir el acceso de todos los usuarios al acceso de solo lectura.

Como base para el control de acceso, puede diseñar roles conceptuales que sean específicos de la aplicación. Los usuarios pueden tener varios roles asignados por un usuario administrativo en la solución de gestión de autorizaciones de la plataforma.

Además de los roles de usuario específicos de la aplicación, CAP también admite algunos de los llamados pseudoroles predefinidos, como authenticated-user. Este rol hace referencia a los usuarios que se han autenticado correctamente.

En el ejemplo mostrado, la anotación @requires se utiliza para controlar que solo los usuarios autenticados puedan ejecutar la acción envOrder.

A continuación, veamos el archivo admin-service-auth.cds, que contiene el control de acceso para AdminService (véase la siguiente figura).

Aquí, también, primero empleamos la directiva using para importar las definiciones a anotar (Authors and Books Entity) del modelo AdminService.

La entidad Autores está anotada con @(requires: 'admin'). Esto determina que solo los usuarios que tienen el rol de administrador específico de la aplicación pueden acceder a la entidad Autores.

Para definir autorizaciones para la entidad Libros, se utiliza la anotación @restrict . Especifica que solo los usuarios con el rol de administrador específico de la aplicación pueden realizar operaciones de LECTURA, CREACIÓN y ACTUALIZACIÓN en la entidad Libros. Las operaciones DELETE también están permitidas solo para usuarios con el rol de administrador, con la restricción adicional de que solo se pueden eliminar libros con un stock de 0.

La anotación @limit proporciona una matriz con cualquier número de objetos de privilegio, donde cada objeto de privilegio tiene la siguiente estructura:

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

Las propiedades del objeto de autorización se definen de la siguiente manera:

• grant

  uno o más eventos (como READ, CREATE, UPDATE y DELETE) a los que se aplica la autorización

• to

  uno o más roles de usuario o pseudoroles a los que se aplica la autorización (opcional)

• where

  una condición de filtro que restrinja aún más el acceso a un nivel de instancia (opcional)

Una solicitud pasa una restricción que consiste en una matriz de privilegios si se cumple al menos uno de los privilegios.

Ahora que hemos visto cómo definir autorizaciones con la ayuda de anotaciones, queremos ver la autenticación a continuación. La autentificación correcta de un usuario constituye la base para poder realizar verificaciones de autorización.

La PAC se transporta con una serie de estrategias de autenticación preconfiguradas.

En producción, la estrategia de autenticación jwt se utiliza por defecto. La identidad de usuario, así como los roles y atributos de usuario asignados, se proporcionan en tiempo de ejecución mediante una instancia vinculada del servicio User Account and Authentication (UAA). Esto se realiza en forma de token JWT en la cabecera Authorization de las solicitudes HTTP entrantes.

Durante el desarrollo, la estrategia de autenticación mocked se utiliza por defecto. Esta estrategia de autenticación utiliza la autenticación básica con usuarios ficticios predefinidos. Opcionalmente, puede definir usuarios adicionales mediante el archivo package.json como se muestra en la siguiente figura:

1
cds env get requires.auth

La autenticación simulada utiliza la autenticación básica. Por lo tanto, puede utilizar la cabecera Authorization con el esquema de autenticación Basic en sus solicitudes con fines de prueba. Las credenciales se especifican en el formulario <user>:<password>, como se muestra en el siguiente ejemplo:

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

Vea el vídeo para ver cómo añadir restricciones al modelo CDS.