![]() | Name | Last modified | Size | Description |
---|---|---|---|---|
![]() | Parent Directory | - | ||
![]() | RBAC_views.sql | 2020-12-01 17:17 | 654 | |
![]() | RBAC_toy_sample.sql | 2020-12-01 11:44 | 1.4K | |
![]() | RBAC_db.sql | 2020-12-01 13:18 | 1.4K | |
![]() | RBAC_rapport.md | 2020-12-01 17:00 | 2.9K | |
![]() | README.md | 2020-12-02 18:44 | 10K | |
![]() | README.html | 2020-12-02 18:44 | 14K | |
![]() | pandoc.css | 2020-12-01 17:13 | 16K | |
Ce TP a trois objectifs :
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.
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.
~/.ssh/config
local pourvous connecter simplement, voir le snippet ci-dessousExemple 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
adjoint
RBAC_views.sql
pg_hba.conf
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.
lambda1
, lambda2
, adjoint
et responsable
chacun avec un mot de passe identique au login.test
dont le propriétaire sera l’utilisateur responsable
.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.
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 :
http_method
crée pour l’occasion,TEXT
),(obj_id, act_id)
,Consulter puis exécuter avec l’utilisateur responsable
dans la base test
le script RBAC_db.sql
.
Peupler la base de départ avec le fichier RBAC_toy_sample.sql
A partir du fichier de départ RBAC_views.sql
:
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
.rbac.matrix
des triplets autorisés (usr_id, obj_id, act_id)
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.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.
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 :
trigger
.RAISE
.CHECK
mais c’est dangereux.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 :
PUBLIC
) à accéder en lecture à toutes les tables du schéma et celles qui seront créées à l’avenir.adjoint
à modifier les affectations entre utilisateurs et rôles.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
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).