Authentification et autorisation
En ce qui concerne la sécurité des applications, les concepts d'authentification et d'autorisation jouent un rôle crucial.
Regardez la vidéo pour obtenir une synthèse de l'authentification et de l'autorisation.
Nous n'avons pas encore configuré d'autorisations dans notre application. Cela signifie qu'il n'existe actuellement aucune restriction et que toutes les demandes ont toujours un accès complet à l'ensemble de l'application. Dans cette leçon, nous allons apprendre à restreindre l'accès à l'application.
Dans un environnement de production, tous les points d'extrémité sont authentifiés par défaut, même si aucune restriction n'est configurée. La méthode d'authentification est personnalisable librement. Pour plus de commodité, un ensemble de méthodes d'authentification est pris en charge prêt à l'emploi pour couvrir les scénarios les plus courants. S'il est nécessaire, pour des raisons de gestion, d'exposer des points de terminaison ouverts à des utilisateurs anonymes, des mesures supplémentaires doivent être prises. La configuration de l'authentification pour l'environnement de production n'est pas abordée dans ce cours.
Comme nous l'avons déjà vu, aucune authentification n'est requise lors du test de l'application dans l'environnement de développement. Nous verrons plus loin comment configurer l'authentification pour l'environnement de test.
Séparation des préoccupations
Dans ce qui suit, nous allons explorer les annotations que vous pouvez utiliser pour contrôler l'accès aux données de gestion à un niveau à granularité fine. Vous pouvez insérer les annotations discutées directement dans les fichiers .cds dans lesquels les services sont définis. Dans notre cas, il s'agit du fichier cat-service.cds pour le CatalogService et du fichier admin-service.cds pour AdminService.
Cependant, il est préférable de stocker les annotations d'autorisation dans différents fichiers .cds afin de les séparer de la définition de service réelle. Ainsi, les définitions de service réelles restent concises et se concentrent uniquement sur la structure. Il vous permet également de donner aux modèles d'autorisation une propriété et un cycle de vie distincts.
Nous allons suivre cette meilleure pratique et créer des fichiers .cds distincts pour modéliser les règles d'accès pour le service de catalogue et le service d'administration. Nous appelons ces fichiers cat-service-auth.cds et admin-service-auth.cds respectivement et les sauvegardons dans le dossier srv de notre projet, tout comme les fichiers avec les définitions de service.
Remarque
@readonly et @requires
Tout d'abord, examinons le fichier cat-service-auth.cds, que nous utilisons pour contrôler l'accès au service CatalogService (voir la figure suivante).
Dans ce fichier, nous importons les définitions des entités Auteurs et Livres ainsi que la définition de l'action submitOrder à partir du modèle CatalogService via la directive using .
Les auteurs et l'entité Livres sont annotés avec @readonly via la directive annotate afin de restreindre l'accès de tous les utilisateurs à l'accès en lecture seule.
Remarque
Comme base pour le contrôle d'accès, vous pouvez concevoir des rôles conceptuels spécifiques à l'application. Les utilisateurs peuvent avoir plusieurs rôles qui sont affectés par un utilisateur administrateur dans la solution de gestion des autorisations de la plate-forme.
Outre les rôles utilisateur spécifiques à l'application, CAP prend également en charge certains pseudo-rôles prédéfinis, tels que authenticated-user. Ce rôle fait référence aux utilisateurs qui ont été authentifiés avec succès.
Dans l'exemple illustré, l'annotation @requires est utilisée pour contrôler que seuls les utilisateurs authentifiés peuvent exécuter l'action submitOrder.
Remarque
@restrict
Examinons ensuite le fichier admin-service-auth.cds, qui contient le contrôle d'accès pour AdminService (voir la figure suivante).
Ici aussi, nous utilisons d'abord la directive using pour importer les définitions à annoter (Entité Auteurs et Livres) à partir du modèle AdminService.
L'entité Auteurs est annotée avec @(requires: 'admin'). Cela détermine que seuls les utilisateurs ayant le rôle d'administrateur spécifique à l'application peuvent accéder à l'entité Auteurs.
Pour définir des autorisations pour l'entité Pages, l'annotation @restrict est utilisée. Il spécifie que seuls les utilisateurs ayant le rôle d'administrateur spécifique à l'application sont autorisés à effectuer des opérations READ, CREATE et UPDATE sur l'entité Books. Les opérations DELETE sont également autorisées uniquement pour les utilisateurs ayant le rôle d'administrateur, avec la restriction supplémentaire selon laquelle seuls les livres avec un stock de 0 peuvent être supprimés.
L'annotation @restrictive fournit un tableau avec un nombre illimité d'objets de privilège, chaque objet de privilège ayant la structure suivante :
1{ grant: <events>, to: <roles>, where: <filter-condition> }Les propriétés de l'objet de privilège sont définies comme suit :
- grant
un ou plusieurs événements (tels que LIRE, CRÉER, METTRE À JOUR et SUPPRIMER) auxquels le privilège s'applique
- to
un ou plusieurs rôles utilisateur ou pseudo-rôles auxquels le privilège s'applique (facultatif)
- where
une condition de filtrage qui restreint davantage l'accès au niveau d'une instance (facultatif) ;
Une requête passe une restriction constituée d'un tableau de privilèges si au moins l'un des privilèges est atteint.
Remarque
Remarque
Les annotations telles que @requires ou @readonly ne sont que des raccourcis pratiques pour @restrict, par exemple :
- @(requires: 'admin') équivaut à @(restrict: [ { grant: '*', to: 'admin' } ])
- @readonly est identique à @(restrict: [ { grant: 'READ' } ])
