Discussion :

[JB4096]

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).
    
    • Martin
  • Directeurs (groupe App : tous les privilèges sur les données).
    
    • Patrick
• JB_Content (user Oracle : création, édition, suppression d'un article).
  
  • Rédacteurs (groupe App : création, édition, suppression d'un article).
    
    • Julien
  • Correcteurs (groupe App : édition d'un article).
    
    • Pierre
• 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).
    
    • Alain
• JB_Visitors (user Oracle : lecture d'un article).
  
  • Visiteurs (groupe App : lecture d'un article).
    
    • Tout autre

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.

[pifor]

est-il possible d'utiliser une procédure stockée pour modifier l'utilisateur Oracle de la session ?

A ma connaissance, il n'y a pas de façon documentée de faire cela.

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

Peut-être avec SYS.ANYDATA mais cela semble bien compliqué pour les paramètre en entrée.
PL/SQL peut par contre facilement retourner un REF CURSOR dont la requête est dynamique mais le code client doit savoir travailler avec.

[mnitu]

Je pense que en fait vous avez besoin seulement de deux utilisateurs Oracle
a) un utilisateur administrateur
b) un utilisateur de connexion
et "n" utilisateurs applicatifs repartis en groupes.

La connexion se fera une seul fois avec l'utilisateur de connexion Oracle qui va mettre dans «*le contexte*» l'utilisateur applicatif. Ensuite en utilisant les "policies" d'Oracle (ou VirtualPrivateBadabase, Fine-GrainedAccessControl,rowLevelSecurity) vous devez être en mesure de gérer toutes les droits sur les objets de l'application. Mais je ne sais pas pourquoi j'ai peur que c'est une application multi-base , est-ce vrai ?

Concernant la deuxième question il va falloir être plus précis. Votre exemple est plutôt «*statique*»: même table, méthode de recherche éventuellement surchargée pour gerer 2 ou 3 paramètres, et en retour ref cursor ou tableau PL/SQL.

[orafrance]

le ALTER SCHEMA peut éventuellement aider aussi non ?

[mnitu]

le ALTER SCHEMA peut éventuellement aider aussi non ?

Franchement je ne vois pas comment . Mais si pouvez expliquer je changerais peut être d'avis

[orafrance]

Franchement, j'ai pas trop appronfondit la question... mais ça parle d'user appli, de changement de user, etc... alors je me dis que ça servirait peut-être... je ne fais que passer

des fois des propositions bêtes déclenchent une idée

[pifor]

J
La connexion se fera une seul fois avec l'utilisateur de connexion Oracle qui va mettre dans «*le contexte*» l'utilisateur applicatif. Ensuite en utilisant les "policies" d'Oracle (ou VirtualPrivateBadabase, Fine-GrainedAccessControl,rowLevelSecurity) vous devez être en mesure de gérer toutes les droits sur les objets de l'application.

Avec XE, vous ne pouvez pas utilisez certaines fonctionnalités liés à la sécurité car elles ne font pas partie de XE.

[JB4096]

Bonsoir,

et merci pour votre intérêt !
Je n'ai malheureusement pas accès au VPD/RLS, limité (si je ne me trompe) à l'édition Entreprise.

Voici un nouveau "plan" pour représenter l'idée :

• un utilisateur est intégré dans un groupe.
• ce groupe dispose de droits dans l'application.
• Afin de limiter les risques, je souhaiterais connecter l'application à Oracle via un user Oracle disposant uniquement des droits suffisants à la réalisation de chaque droit du groupe de l'utilisateur (de l'application).

Je tente à l'heure actuelle une autre solution :

• un seul user Oracle disposant de tous les droits ().
• l'utilisateur (de l'application) se connecte à cet user et annonce son groupe à la base de donnée (via dbms_application_info.set_client_info).
• À chaque tentative d'action, la base vérifie que le groupe attaché au client_info dispose des droits nécessaires.

Le problème : un utilisateur pourrait récupérer le client_info d'un utilisateur précédent. Bien sûr, il m'est possible d'écraser celui-ci à chaque connexion mais je subodore une faille énorme.


À propos de la deuxième question, l'action pourrait appeler une requête, une procédure ou une fonction et recevoir des données ou un booléen. Le plus simple serait de pouvoir créer une fonction de type :

• vérification des droits du groupe.
• appel de la requête de manière classique (hors fonction, comme si j'entrais la requête dans Sqlplus).
  
  J'imaginais pouvoir réaliser ceci avec un simple EXECUTE IMMEDIATE :
  
  • "EXECUTE IMMEDIATE 'SELECT :var FROM DUAL' BULK COLLECT INTO array_out?! USING array_in?!;" pour recevoir 1 : 1
  • "EXECUTE IMMEDIATE 'SELECT ID, Auteur FROM Articles' BULK COLLECT INTO array_out?! USING array_in?!;" pour recevoir ID : 1, Auteur : 51 - ID : 2, Auteur : 4 - ID : 3, Auteur : 80 - etc
  • "EXECUTE IMMEDIATE 'exec uneProcedure('Essai');' BULK COLLECT INTO array_out?! USING array_in?!;" pour recevoir TRUE.

Merci encore et bonne soirée !

[pifor]

A ma connaissance, il n'y a pas de façon documentée de faire cela.

Je précise que le comportement par défaut des procédures stockées est de s'exécuter avec les droits du propriétaire de la procédure et non avec les droits de l'appelant de la procédure. Ce mécanisme permet de ne donner aucun privilège sur un objet table ou vue mais de donner uniquement un droit d'exécution sur les objets PL/SQL qui manipulent la table ou la vue. Le mécanisme peut être étendu aux lectures si on autorise uniquement l'exécution de procédures stockées qui retournent des curseurs.

Cette approche est souvent mise en avant par Tom Kyte pour assurer (selon lui) la sécurité maximale des données dans la base.

[orafrance]

sauf en précisant AUTHID comme indiqué ici : http://www.developpez.net/forums/sho...d.php?t=158315

[mnitu]

Oracle XE ? C'est un jouet ! Bon cella ne change en rien ma faute .

Bref si vous envisages d'utiliser du SQL dynamique alors rien ne vous empêche de faire le même chose que le VPD ça veut dire modifier dynamiquement les requêtes en fonction du «*contexte*». A propos, en Oracle 10 en PL/SQL vous utilisez l'équivalent du BULK COLLECT INTO par défaut, est-ce que c'est aussi vrai pour XE ?

Pour sélectionner les données de la table articles vous n'avez besoin de rien, tout le monde peut sélectionner dans la table des articles. Il vous reste à utiliser des procédures pour modifier, supprimer et insérer les données. Et cella Oracle XE sait le faire il me semble.

[JB4096]

Bonsoir,

il se pourrait qu'un utilisateur n'aie pas les droits pour lire un article.

Actuellement, j'hésite entre deux solutions :

• Créer une procédure capable de vérifier les droits de l'utilisateur puis d'appeler une autre procédure/fonction/requête.
  
  Avec tout ce que cette solution implique de dynamique.
• Insérer dans chaque procédure un entête afin de vérifier que l'utilisateur aie le droit de poursuivre.
  
  Dans ce cas, je devrai créer une procédure par "groupe" de requêtes, est-ce viable ? Par exemple :
  

  • Procédure LireArticle (type, condition).
    
    • Dans le cas de LireArticle (id, 4) : SELECT Id, Auteur, Nom, Description, Texte FROM Articles WHERE Id = 4;
    • Dans le cas de LireArticle (auteur, 4) : SELECT Id, Auteur, Nom, Description, Texte FROM Articles WHERE Auteur = 4;

Une nouvelle fois merci,
bonne soirée !

[LeoAnderson]

A mon avis, le plus simple est de définir x roles Oracle, les associer à l'utilisateur Oracle non-admin qui décide ensuite quel(s) rôle(s) il souhaite activer (enfin, l'appli décide pour lui)
http://download.oracle.com/docs/cd/B...htm#sthref9925

Par contre, sous XE, je suis pas sûr que ça marche...

Mais bon, on ne peut pas non plus vouloir le beurre, l'argent du beurre, le c.. de la crémière et les félicitations du crémier !

[mnitu]

...
[INDENT]Dans ce cas, je devrai créer une procédure par "groupe" de requêtes, est-ce viable ? Par exemple :

• Procédure LireArticle (type, condition).
  
  • Dans le cas de LireArticle (id, 4) : SELECT Id, Auteur, Nom, Description, Texte FROM Articles WHERE Id = 4;
  • Dans le cas de LireArticle (auteur, 4) : SELECT Id, Auteur, Nom, Description, Texte FROM Articles WHERE Auteur = 4;

Une nouvelle fois merci,
bonne soirée !

Vous aimez vous compliquer la vie

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
Select * from table where id  = 3
et 
select * from table where id between 3 and 3

c'est la même chose.
Que le select se fait par auteur ou par id ne change en rien les droits de lecture de la table Article.

Vous devez gérer une table des utilisateurs, une table des groupes, une table des utilisateurs par groupe, une table de traitements (Article, commentaires, etc.) une table d'accès (select, insert, update, delete) par traitement et par groupe d'utilisateurs. Ensuite chaque utilisateur est authentifié par l'application, sa groupe est identifiée, et pour chaque traitement la table des accès indique les opérations autorisées. Avant d'effectuer une opération vous vérifiez l'accès et vous envoyez le requête sql ou pas. Cette logique vous pouvez la gérer dans les procédures PL/SQL ou dans PHP par des requête construite dynamiquement.