Index of /romuald.thion/files/Enseignement/TIW4/TP-Authorization-PG

	Name	Last modified	Size	Description
	Parent Directory		-
	RBAC_db.sql	2020-12-01 13:18	1.4K
	RBAC_rapport.md	2020-12-01 17:00	2.9K
	RBAC_toy_sample.sql	2020-12-01 11:44	1.4K
	RBAC_views.sql	2020-12-01 17:17	654
	README.html	2020-12-02 18:44	14K
	README.md	2020-12-02 18:44	10K
	pandoc.css	2020-12-01 17:13	16K

TP TIW4 2020-2021 “autorisation” : sujet

• TP TIW4 2020-2021 “autorisation” : sujet
  • Introduction
    • Modalités de rendu
    • Conseils
    • Changelog
  • Prise en main
    • Machine virtuelle
    • Création de bases et utilisateurs
  • Le modèle de contrôle d’accès applicatif
    • Schéma de départ
    • Jeu d’essai
    • Calcul des décisions d’accès
    • Extension aux sessions
  • Gestion des droits sur le modèle
    • Modèle d’administration, base
      • Remarque
    • Délégation à l’adjoint

Introduction

Ce TP a trois objectifs :

• découvrir et utiliser un système de gestion de droits représentatif des modèles à rôles, ici celui de PostgreSQL;
• modéliser des droits à partir d’une spécification en langue naturelle, par exemple pour contrôler les accès dans une application de gestion;
• faire un peu de modélisation relationnelle.

Il y a donc deux modèles de contrôle d’accès : celui du SBGD PostgreSQL lui même et celui d’une hypothétique application. En ce sens, le modèle de contrôle système de PostgreSQL est le modèle d’administration de votre modèle de contrôle applicatif que vous implémentez sous forme relationnelle.

Modalités de rendu

• Le TP est à réaliser en binôme TIW.
• Le TP est à rendre en fin de séance, le mercredi 02/12/19 à 19h00 dans la case https://tomuss.univ-lyon1.fr/ idoine.
• Le rendu prend la forme d’un unique rapport MD :
  • le rapport doit être auto-suffisant, avec tous les extraits de SQL nécessaire à la reproduction du TP.
  • le rapport doit être vérifable, avec tous les élements qui montrent que les tests on été effectués et sont reproductibles

Une trame de départ à compléter est fournie, c’est le fichier RBAC_rapport.md. Cette trame est obligatoire, elle reprend la structure du sujet et contient des questions auxquelles il faut répondre.

Conseils

• documentation PostgreSQL locale https://forge.univ-lyon1.fr/bd-pedago/bd-pedago
• utiliser https://www.byobu.org/ ou https://github.com/tmux/tmux sur la VM pour travailler à plusieurs et résister aux déconnexions SSH/VPN
• configurer votre fichier ~/.ssh/config local pourvous connecter simplement, voir le snippet ci-dessous

Exemple d’extrait du fichier ~/.ssh/config, ici pour le groupe 42, après avoir mis la clef privée ~/.ssh/tiw4-authentication.pem :

# TP TIW4 Authorization PostgreSQL
Host tiw4-authorization-pg
  HostName tiw4-authorization-pg-42.tiw4pg.os.univ-lyon1.fr
  User ubuntu
  IdentityFile ~/.ssh/tiw4-authentication.pem

Changelog

• 2020-12-02T18:43+01:00 : ajout commentaire à la fin sur les niveaux de droits
• 2020-12-02T18:13+01:00 : précision sur les rôles délégables via l’héritage
• 2020-12-02T18:08+01:00 : clarification à la fin sur les droits de adjoint
• 2020-12-01T17:17+01:00 : plusieurs typos dans RBAC_views.sql
• 2020-12-01T17:02+01:00 : correction question pg_hba.conf
• 2020-12-01T14:02+01:00 : version initiale

Prise en main

Machine virtuelle

Le nom DNS d’une VM Ubuntu 20.04.1 avec PostgreSQL de configuré vous est fournie dans Tomuss. La clef privée pour y accéder est la même que le précédent TP TIW4, elle est rappellée dans le Discord.

Création de bases et utilisateurs

• créer les utilisateurs (avec droit de login) PostgreSQL lambda1, lambda2, adjoint et responsable chacun avec un mot de passe identique au login.
• créer une base test dont le propriétaire sera l’utilisateur responsable.
• dans la base test, réduire les droits sur le schéma public.

La configuration de PostgreSQL déjà fournie dans les fichiers /etc/postgresql/13/main/pg_hba.conf et /etc/postgresql/13/main/postgresql.conf doit permettre de se connecter depuis la VM d’un autre groupe.

Le modèle de contrôle d’accès applicatif

On va commencer par le modèle applicatif modélisé selon le modèle RBAC. C’est le modèle qui permet dans votre application de déterminer les droits des utilisateurs en son sein. Les ressources dont on va contrôler les accès sont les routes d’une API REST :

• les actions sont les méthodes HTTP usuelles du type énuméré http_method crée pour l’occasion,
• les objets sont des chemins relatifs représentée par desc chaînes de caratcères (type TEXT),
• les permissions sont identifiées par des paires (obj_id, act_id),

Schéma de départ

Consulter puis exécuter avec l’utilisateur responsable dans la base test le script RBAC_db.sql.

Jeu d’essai

Peupler la base de départ avec le fichier RBAC_toy_sample.sql

Calcul des décisions d’accès

A partir du fichier de départ RBAC_views.sql :

• définir 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 (usr_id, obj_id, act_id)
• à partir de la vue précédente, écrire la fonction rbac.authorized_actions(usr_name, obj_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 le jeu d’essai. Vérifier en particulier que votre calcul est robuste quel que soit le contenu de rbac.inherits.

Vous pourrez avoir des difficultés sur la vue récursive, consulter par exemple ce tutoriel.

Extension aux sessions

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 :

• Attention, en PostgreSQL, pour créer un trigger il faut d’abord définir une fonction dont le type de retour est trigger.
• Pour lever un message d’information ou une exception (qui provoquera la fin de la transaction), voir la commande RAISE.
• On pourrait essayer d’implémenter avec un CHECK mais c’est dangereux.

Gestion des droits sur le modèle

Modèle d’administration, base

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

• responsable le propriétaire de la base qui est aussi l’administrateur du point de vue du système RBAC.
• adjoint un adjoint au précédent qui va disposer de droits moindre.

On va donner les droits suivants :

• Autoriser tous les utilisateurs (PUBLIC) à accéder en lecture à toutes les tables du schéma et celles qui seront créées à l’avenir.
• Autoriser en plus, l’utilisateur adjoint à modifier les affectations entre utilisateurs et rôles.

Remarque

Il y a des droits à trois niveaux différents d’organisation des données dans PostgreSQL :

• DATABASE : CREATE | CONNECT | TEMPORARY | TEMP
• SCHEMA : CREATE | USAGE
• TABLE : SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER

Et aussi des droits sur les autres objets (DOMAIN, FUNCTION etc.)

Si vous révoquez les droits à un niveau supérieur (e.g., CONNECT ON DATABASE) cela ne modifie pas les droits sur les schémas et tables aux niveaux inférieurs (quand vous redonnez CONNECT, ca revient comme avant). Et, piégeux, il y a deux privilèges niveau schéma : CREATE | USAGE qu’on oublie souvent.

Finalement avoir accès SELECT à une table il faut que le trois niveaux laissent passer :

• CONNECT ON DATABASE
• USAGE ON SCHEMA
• SELECT ON TABLE

Délégation à l’adjoint

Ensuite, on souhaite autoriser adjoint à 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 qu’on appelle les rôles délégués.

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 adjoint.

En utilisant le mécanisme de row security policies avec la commande CREATE POLICY faites en sorte que adjoint ne puisse modifier (INSERT, DELETE, UPDATE) les tables rbac.pra et rbac.inherits que pour les rôles délégués, c’est-à-dire ceux où le nouvel attribut rbac.role.delegate est true.

Pour rbac.inherits, adjoint 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. En d’autres termes on peut ajouter des enfants à un rôle délégable, mais pas des parents (ce qui créerait des droits).