Securité - C#/.NET managed - Programmation
Marsh Posté le 22-02-2006 à 09:34:01
Concernant l'aspect "requêtes", si tu as bien fixé les droits sur ta BDD, le logiciel n'a qu'à gérer les exceptions du pilote ODBC (si c'est ce que tu utilises) pour les lectures/écritures refusées.
Marsh Posté le 22-02-2006 à 09:37:58
oui mais les utilisateur s'inscrivent via internet bon je n'ai pas trop envie de créer autant d'utilisateurs...
Marsh Posté le 22-02-2006 à 13:18:13
Reprenons depuis le début.
Que fait ton application ?
Que doit faire l'utilisateur pour l'utiliser ? S'inscrire ? (comment, avec quoi) Te contacter directement ?
Sur quels critères sont déterminé les droits des utilisateurs ? (point le plus important à mon sens)
Est-ce que ces droits sont attribués de manière automatique ou geré à la main ?
Marsh Posté le 22-02-2006 à 13:43:35
Tout d'abord il s'agit d'un site de commande d'animations.
Pour ce, les client on un contrat avec nous.
Pour ce on crée x compte (parfois des centaines) pour ce clients.
Donc on a créé les tables suivantes:
- Client
- Utilisateur (plusieurs utilisateurs par Client)
- Goupes_d_utilisateurs (plusieurs utilisateurs on les memes droits)
- Application
- Modules (plusieurs modules par applications)
- Access (m à n entre Modues et Goupes_d_utilisateurs)
Les droits sont donc gerés manuellement dans un premier temps en tout cas mais il n'est pas a exclure que se soit automatique plus tard.
J'utilise MSSQL mais le problèmes des Application web (d'après ce qu'on me dit) c'est que un seul utilisateur se connecte. Sinon j'aurais pu a la limite laisse MSSQL gerer ca! (au moins pour les acces au tables)
Marsh Posté le 22-02-2006 à 16:42:49
Donc si j'ai bien compris, tu crée des droits dans une base 'perso'.
Lorsque la personne se log, ton application web va chercher les droits dans ta base 'perso' pour brider certaines fonctions (pas d'affichage). Mais tu souhaiterais que celà bride aussi les droits sur tes tables.
Donc tu dois gérer deux comptes :
- celui pour faire l'affichage (je bride ou pas telle fonction)
- celui qui limite l'accès aux tables
En relisant le premier post, j'ai l'impression que tu veux recoder la gestion des utilisateurs sur la base via ton module de sécu.
Je serais à ta place, je me code une interface d'administration.
Cette interface me permet à chaque fois que j'ajoute un utilisateur :
- de l'ajouter dans ma base 'perso' de gestion des droits.
- d'ajouter son groupe et les droits associés dans la liste des utilisateurs de la BDD si ce groupe n'existe pas déjà (à noter que pour la BDD, ce que nous appelons un groupe correspond pour elle à un utilisateur).
Au niveau de ton programme :
- L'utilisateur se log
- Ton programme se connecte pour interroger ta base des droits perso(avec un compte générique en lecture seule)
- Le programme récupère la liste des droits ainsi que le groupe auquel l'utilisateur appartient. Le groupe servira de login pour la suite des transactions SQL.
- Chargement des restrictions dans ton programme
- Connexion à la base avec l'utilisateur "nom_du_groupe".
Le fait d'avoir une entrée par groupe dans la BDD limite la population des comptes (ce que tu souhaites) mais en revanche tu perds un peu en tracabilité car tu ne sais pas quel utilisateur a fait une connerie dans le log de la base, tu connaitra seulement son groupe.
Tel que j'ai compris ton histoire, tu es parti pour recoder la gestion des utilisateurs de la BDD et analysant le contenu des requêtes SQL.
Marsh Posté le 24-02-2006 à 16:24:53
c'est fréquent de devoir faire cela. Moi perso je ne sis pas trop chaud d'utiliser ce que le client à récupéré au premier échange de donnée, et que c'est le client qui gere la sécurité. Dans son cas, un webservice est accessible. N'importe qui peut construire une applic pour foutre le bordel dans sa base. La sécurité doit donc être intégré au niveau du WebService puisque c'est lui qui attaque la base de données. Dans ce cas la, moi j'opterais pour un échange d'informations spécificique à chaque échange afin que le web service puisse vérifier l'authenticité du client. Si le WebService est statefull pour l'utilisateur, il est possible de stocké cela dans l'instance du client et donc d'éviter un échange d'informations supplémentaires entre le client et le serveur à chaques échanges.
Marsh Posté le 21-02-2006 à 17:12:16
Bonjour,
Je doit créer un programme composé de 3 parties: une interface graphique, des web service pour gerer les données et un module de sécurité.
Je doit donc créer un module de sécurité pour savoir si l'utilisateur en cours peut exécuter tel ou tel requete. Et du coté de l'inteface graphique savoir si il faut afficher ou pas certaines informations.
Donc je pensait gerer ces droits dans une DB en fesant une table avec tout les modules de mon programme, une table utilisateur et une table pour la liaison entre les 2 (relation de m à n).
Mais comment mon module de sécurité doit il communiquer avec les autres partie de mon programme est ce que mon programme demande a chaque fois: "est ce que je peut effectuer tel requete" et le module répond oui ou non le programme en fesant ce qu'il veut.
Ou alors 2ème solution: mon programme demande au module de sécurité d'exécute cette action et le module l'exécute uniquement si les droits de l'utilisateur sont suffisant. => cette solution me parait mieux mais je ne voit pas trop comment faire alors pour savoir si je doit ou pas afficher les informations dans l'interface graphique...
D'avance merci pour tout vos éclairsissments et sugestions
Ben
Message édité par the big ben le 22-02-2006 à 09:24:30