Bonjour,
voici quelques semaines que je tourne en rond à la recherche de la solution ultime pour gérer les privilèges des utilisateurs d'une application (et non les utilisateurs Oracle). J'espère ne pas être trop indigeste (vous pouvez éventuellement sauter à "Dans le meilleurs des mondes").
Le décor : Debian, Oracle XE et PHP.
L'idée :
un utilisateur (de l'application) appartient à un groupe, ce groupe a des droits et se connecte à Oracle via un utilisateur spécifique (limité en privilèges).
un groupe est donc toujours limité par ses propres droits mais également par les privilèges de l'user Oracle avec lequel il se connecte.
L'exemple :
- Martin appartient au groupe Administrateurs qui se connecte grâce à l'user JB_System.
- Son groupe lui offre tous les droits (structure et données).
- L'utilisateur Oracle JB_System lui offre tous les droits utiles pour la gestion de l'application.
- Patrick appartient au groupe Directeurs qui se connecte également grâce à l'user JB_System.
- Son groupe lui offre l'opportunité de modifier toutes les données.
- L'utilisateur Oracle JB_System lui offre tous les droits utiles pour la gestion de l'application.
- Julien appartient au groupe Rédacteurs qui se connecte grâce à l'user JB_Content.
- Son groupe lui offre l'opportunité d'insérer, de modifier et de supprimer des articles.
- L'utilisateur Oracle JB_Content lui offre insert, update, delete sur la table Articles.
- Pierre appartient au groupe Correcteurs qui se connecte grâce à l'user JB_Content.
- Son groupe lui offre uniquement l'opportunité de modifier des articles.
- L'utilisateur Oracle JB_Content lui offre insert, update, delete sur la table Articles.
- Alain appartient au groupe Utilisateurs qui se connecte grâce à l'user JB_Users.
- Son groupe lui offre l'opportunité de lire des articles ainsi que de les commenter.
- L'utilisateur Oracle JB_Users lui offre select sur la table Articles et insert, update sur Commentaires.
- * appartient au groupe Visiteurs qui se connecte grâce à l'user JB_Visitors.
- Son groupe lui offre l'opportunité de lire des articles.
- L'utilisateur Oracle JB_Visitors lui offre select sur la table Articles.
Différement :
- JB_System (user Oracle : tous les privilèges).
- Administrateurs (groupe App : tous les privilèges).
- Directeurs (groupe App : tous les privilèges sur les données).
- JB_Content (user Oracle : création, édition, suppression d'un article).
- Rédacteurs (groupe App : création, édition, suppression d'un article).
- Correcteurs (groupe App : édition d'un article).
- JB_Users (user Oracle : lecture d'un article, création&édition d'un commentaire).
- Utilisateurs (groupe App : lecture d'un article, création&édition d'un commentaire).
- JB_Visitors (user Oracle : lecture d'un article).
- Visiteurs (groupe App : lecture d'un article).
Je suis donc parti sur une première idée : une table des utilisateurs, une table des groupes et une table des droits.
- L'utilisateur se connecte à l'application.
- L'application se connecte à Oracle via JB_Visitors.
- L'application demande à Oracle le véritable user du groupe.
- Si le groupe de l'utilisateur propose un user Oracle différent : l'application se reconnecte via JB_*.
- L'utilisateur souhaite effectuer une action.
- L'application vérifie dans la table Actions que celui-ci en a le droit.
- Si oui : l'application recoit la requête, attache les données, exécute la requête puis en recoit le résultat.
- Si non : l'application recoit une erreur.
L'application est donc obligée, lorsque Martin (Administrateurs) souhaite ajouter un utilisateur, de se connecter deux fois à la base et d'expédier trois requêtes.
Dans le meilleurs des mondes :
- Martin se connecterait via JB_Visitor mais en s'annoncant.
- Oracle comprendrait cet ordre.
- Oracle vérifierait le groupe de Martin et modifierait l'user vers JB_System.
- Martin tenterait d'effectuer une action :
- L'application expédierait l'action et les données à Oracle.
- Oracle vérifierait que Martin en ai le droit.
- Si oui : la requête serait traitée et l'application recevrait le résultat de la requête.
- Si non : l'application recevrait une erreur.
Je pensais donc à diverses procédures/fonctions dont :
- Connection (id de Martin).
- Action (id de l'action, ..., une flopée de données).
Voici enfin les questions :
- est-il possible d'utiliser une procédure stockée pour modifier l'utilisateur Oracle de la session ?
- est-il possible de passer des données (de nombre et de type inconnus) à une fonction et d'espérer recevoir en retour des données (également de nombre et de type inconnus).
- Imaginons que je souhaite lire l'article 20 : j'appelle la fonction Action (101, 20) :
- 101 correspond au numéro de l'action "lecture d'article défini" (SELECT * FROM Articles WHERE ID = :id).
- Je reçois :
- ID : 20, Auteur : 'Julien', Nom : 'Quel pavé', Description : 'J''ai bien conscience que la suite est un pavé');
- Imaginons que je souhaite lire les articles entre 1 et 30 : j'appelle la fonction Action (110, 1, 30) :
- 110 correspond au numéro de l'action "lecture d'articles entre" (SELECT * FROM Articles WHERE ID BETWEEN :debut AND :fin).
- Je reçois :
- ID : 1, Auteur : 'Julien', Nom : 'Mhhh', Description : 'Qui suis-je, ou vais-je, dans quel étât j'aire ?');
- ID : 20, Auteur : 'Julien', Nom : 'Quel pavé', Description : 'J''ai bien conscience que la suite est un pavé');
- ID : 24, Auteur : 'Julien', Nom : 'Toujours', Description : 'Un pavé qui devrait le rester.');
Merci beaucoup pour votre aide.
En espérant ne pas avoir effrayé trop de monde ,
Julien.
Partager