TD/TP TIW4 2019-2020 "autorisation" : conception d'une base RBAC dans PostgreSQL

On souhaite développer une solution de gestion des droits par les rôles, qui serait par exemple intégrée à l'API REST du backend d'une application de gestion.

Pour commencer :

Les trames des deux premiers fichiers RBAC_db.sql et RBAC_views.sql sont fournies.

Modalités de rendu :

Le sujet est à réaliser seul ou en binôme. Dans la case https://tomuss.univ-lyon1.fr/ idoine, déposer un fichier zip contenant les scripts SQL indiqués et le dessin de la section Jeu d'essai pour au plus tard le mercredi 04/12/19 à 19h00

Schéma de bases de données RBAC, fichier RBAC_db.sql

Il s'agit dans un premier temps de réaliser un schéma de base de données SQL pour le modèle RBAC présenté en cours (slide 30). On ne gèrera pas les sessions utilisateurs pour l'instant.

On utilisera un serveur PostgreSQL, local ou bd-pedago.univ-lyon1.fr par exemple, pour réaliser la base de données. Si vous êtes en local créer un utilisateur tiw4-auth et sa base de données éponyme dont il est propriétaire. Voir cet exemple pour la création. Sur bd-pedago.univ-lyon1.fr, utilisez simplement la base d'un des membres du binome. Enfin, créer un schéma rbac et modifier le search_path pour votre base (cas local) ou votre utilisateur, voir l'exemple ci dessous :

CREATE SCHEMA IF NOT EXISTS rbac; ALTER DATABASE "tiw4-auth" SET search_path TO "$user", rbac, public; -- un sous-ensemble de https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods -- https://www.postgresql.org/docs/current/datatype-enum.html CREATE TYPE http_method AS ENUM ('GET', 'POST', 'PUT', 'DELETE'); -- DROP TYPE IF EXISTS http_method;

Compléter le script RBAC_db.sql qui crée les différentes tables dans le schéma rbac en prenant en compte les remarques suivantes :

Jeu d'essai, fichier RBAC_toy_sample.sql

Faites un dessin d'une (petite) politique RBAC avec un maximum de cas particuliers. Produire le script SQL correspondant pour votre schéma.

Calcul des décisions d'accès, fichier RBAC_views.sql

A partir du fichier de départ RBAC_views.sql, écrire la vue récursive rbac_inherits_trans(role_id, role_id) qui à chaque rôle donne l'ensemble de ses ancêtres, c'est-à-dire la fermeture réflexive et transitive de la relation d'héritage direct rbac_inherits.

Définir la vue rbac_matrix des triplets autorisés (user_id, object_id, action_id) puis à partir de celle-ci écrire la fonction rbac_authorized_actions(user_name, object_name) qui prend en paramètre un nom d'utilisateur et un nom d'objet et renvoie la liste des actions autorisées sur cet objet pour cet utilisateur.

Créer une fonction rbac_count_auth_users(role_id) qui compte le nombre d'utilisateur implicitement autorisés à endosser le rôle, c'est-à-dire y compris à travers l'héritage via les rôles fils.

Tester sur votre jeu d'essai. Vérifier en particulier que votre calcul est robuste quel que soit le contenu de rbac_inherits.

Modélisation, fichier RBAC_dpt_sample.sql

Le département d'informatique a décidé d'investir dans un système de gestion électronique des notes. L'API REST est la suivante :

Voici les règles de contrôle d'accès que le département souhaite voir appliquées :

On supposera 2 UEs tiw4 et tiw1. L'utilisateur romuald est responsable de la première UE, lionel de la seconde. L'utilisateur emmanuel est chargé dans la deuxième. Il y a aussi un utilisateur nicolas qui est seulement enseignant.

Créer ce jeu d'essai pour votre modèle de données et vérifier les droits des utilisateurs.

Gestion des droits sur le modèle, fichier RBAC_dpt_security.sql

Maintenant, on veut gérer les droits sur cette base de données avec le système de droit de PostgreSQL. Appelons :

Autoriser tous les utilisateurs à accéder en lecture à toutes les tables du schéma et celles qui seront créées à l'avenir. Autoriser deputy à modifier les affectations entre utilisateurs et rôles.

Autoriser deputy à modifier les affectations entre rôles et permissions et la hiérarchie de rôle mais on souhaite limiter ces modifications à un sous enssemble des rôles existants. Pour cela, ajouter une colonne booléenne delegate à la table rbac_role, fausse par défaut. Cette colonne indique si la modification de ce rôle peut être déléguée (à l'utilisateur deputy).

En utilisant le mécanisme de row security policies avec la commande faites en sorte que deputy ne puisse modifier les tables rbac_pra et rbac_inherits que pour les rôles délégués. Pour rbac_inherits, deputy ne pourra que donner des permissions à d'autres rôles par l'héritage de rôles déléguables, mais ne pourra pas en acquérir.

Extension du modèle, fichier RBAC_sessions.sql

Créer la table rbac_session et les relations associées pour ajouter les sessions à votre modèle.

Ensuite, créer un trigger qui garantit la contrainte d'inclusion des rôles endossés dans la session. On ne gèrera que les rôles explicitement affectés via rbac_ura, sans prendre en compte l'héritage.

Définir la fonction rbac_authorized_actions_session(user_name, object_name) qui renvoie la liste des actions autorisées à travers les rôles que l'utilisateur endosse dans ses sessions.

Remarques :

Pour aller plus loin : questions ouvertes

On ne le fera pas là, mais on le note pour plus tard, à l'examen (par exemple).