Modification des restrictions d'accès au niveau de l'enregistrement dans les applications ASP classiques

Question

Comme le titre l'indique, il m'a été demandé de fournir une estimation pour la mise à niveau d'une application ASP existante.

Le mécanisme de sécurité actuel contrôle l'accès aux différentes parties de l'application (restrictions au niveau de la page), mais ne dispose d'aucun mécanisme permettant de marquer des enregistrements individuels comme restreints. L'attribution des droits à un utilisateur (en utilisant l'existant, le code de gestion d'accès personnalisé) est pas de problème, mais l'application des droits est une autre affaire - chaque page asp a intégré sql - il n'y a pas d'utilisation de procédures stockées, des objets, etc.

Est-ce la seule solution pour modifier chaque table et requête, ou y a-t-il un meilleur moyen? Toute indication, suggestion ou prière serait la bienvenue.

Ceci est un ASP classique, s'exécutant sur IIS6, par rapport à une base de données Oracle.

Mise à jour: Voici un scénario utilisateur. Nous avons des utilisateurs, des gestionnaires, des directeurs et des responsables de projets de revalorisation. Les responsables peuvent voir les données créées par les utilisateurs qui leur font rapport, mais pas les utilisateurs qui relèvent d'autres gestionnaires. Les utilisateurs ne peuvent pas voir les données créées par des gestionnaires. Même chose avec les directeurs - ils peuvent voir vers le bas, mais leurs rapports ne peuvent pas voir.

Answer 1

En supposant que vous ayez besoin d'une granularité maximale, la possibilité d'accorder chaque ligne à un très grand nombre d'utilisateurs, alors vous avez une relation plusieurs-à-plusieurs, oui?

vous devez donc appliquer le schéma suivant:

Ajouter une table des utilisateurs.

Ensuite, pour chaque tableau à usage limité, les éléments suivants:

• le renommer TABLENAME + "_base".

• créer un grand nombre à plusieurs table associés id de la table avec un ID utilisateur , appelé tablename + "allowed_user".

• créer une vue avec le nom de la table nom qui se joint à tablename_base table_name_allowed_user, avec un select * from tablename_base et user_id de tablename_allowed_user. Cette vue doit répondre aux exigences d'Oracle pour être "intrinsèquement modifiable".

Maintenant vient la partie difficile. Vous devez ajouter "et user_id = $ user_id" à chaque requête. Trouvez les différentes fonctions que vous utilisez pour faire des requêtes. Envelopper ces fonctions dans celles qui obtiennent l'identifiant de l'utilisateur de la session et ajouter ce prédicat. Une manière passable de faire ceci est de lire la chaîne de sélection, de trouver tous les "où" s (pour les sous-requêtes il peut y avoir plus d'un), et de le remplacer par "where (user = $ user)". Pour les requêtes qui n'ont pas de where, vous devrez insérer ceci avant tout "group by" ou "order by". C'est fragile, alors évidemment vous testerez que cela fonctionne pour toutes les pages (vous avez un test automatisé pour toutes les pages, n'est-ce pas?), Et ajoutez des hacks pour couvrir des cas spéciaux.

Les instructions de "mise à jour" n'auront pas à être modifiées; "insert" insérera vraisemblablement les deux à la vue et ensuite fera une insertion distincte à la table "allow_user" de la table avec l'id de l'utilisateur d'insertion, pour accorder automatiquement l'accès d'insertion d'utilisateur à ce qu'il a inséré.

Si votre nombre d'utilisateurs est plus limité ou si vous restreignez les types d'utilisateurs, vous pouvez utiliser une stratégie avec plusieurs vues nommées pour l'utilisateur ou le type; alors vous devrez remplacer les noms de tables dans les requêtes avec les vues appropriées.

Answer 2

Cela semble être le moment idéal pour implémenter la sécurité au niveau des lignes. Oracle a un package DBMS_RLS qui vous permet de définir des stratégies d'accès arbitraires qui peuvent être appliquées à une ou plusieurs tables limitant les lignes qu'un utilisateur particulier est autorisé à voir. Conceptuellement, lorsqu'un utilisateur émet une requête sans filtre sur une table protégée, à savoir

SELECT * 
    FROM my_table 

Oracle et insère automatiquement de manière transparente une clause WHERE définie par votre politique de sécurité qui limite le jeu de résultats. Vous ne devriez pas avoir besoin de modifier le code SQL que votre application est en train d'exécuter.