Discussion :

[apoingsfermes]

Bonjour,

Je me demande si Active Directory convient pour gérer les droits d'accès à un site web. Le site que je développe doit offrir des fonctionnalités différentes en fonction du type d'utilisateur qui se connecte.

Je sais qu'il est possible d'utiliser une base Active Directory pour stocker ces informations quand on utilise les Membership et les Roles ASP.NET, mais je veux étendre moi-même le schéma de mon AD (rajouter des classes métier), et utiliser l' authentification Windows normale.

Là où j'ai un peu de mal, c'est pour modéliser les niveaux d'accès dans Active Directory : faut-il créer des nouveaux groupes de type groupe de sécurité ?

D'autre part -et surtout-, je ne vois pas comment modéliser dans AD des groupes fonctionnels, regroupant les utilisateurs. Le métier est la téléphonie. Il y a plusieurs types de groupe (d'appel, d'interception, d'écoute), et plusieurs instances par type (des groupes par client, par site...). Il me semble que les groupes AD permettent de gérer la première problématique (le type de groupe), mais pas la deuxième (plusieurs instances de chaque type).

En fait, dans un premier temps j'ai concu une base de donnée relationnelle pour stocker mes infos (utilisateurs, groupes, objets métier), mais je me rends compte que ce sont essentiellement des ressources, des utilisateurs, et des droits, donc des objets AD. Si je mets tout dans AD, je peux gérer au même endroit les objets métier, les utilisateurs et les droits d'accès au site web. Et j'évite de répliquer des infos dans plusieurs bases.
Il y a juste les quelques points mentionnés plus haut qui me chiffonnent.

Voilà, voilà! Hem, c'est pas très technique, comme question, mais je me dis que ça peut intéresser du monde...

[B.AF]

Je ne vois pas en quoi tu as besoin d'AD.;-)

Tu cherches a creer des workgroups, dans ton appli avec pour chaque workgroup un lien parent ou enfant vers un domaine fonctionnel.

Je vois pas pourquoi tu ne geres pas cela au niveau de la db.

Basiquement, si c interesse, j'ai une appli qui fait ça tres bien, sauf que le plus simplement du monde, j'empeche pas les utilisateurs d'acceder aux ressources : ils ne les voient pas. A la place de faire un decoupage technique, fais un decoupage fonctionnel, c'est beaucoup plus simple et beaucoup plus efficace. Derriere, au niveau des acces aux données tu n'as alors besoin que d'un seul user et de regler ton pooling.

[apoingsfermes]

C'est une appli d'administration que je développe, c'est pour ça que je pense à Active Directory.
Et puis parce que certaines informations (utilisateurs, ressources) se trouvent déjà dans l'AD.
Et puis parce que si je n'utilise que AD, je peux éviter des manips (gestion de l'AD ET de la nouvelle base), et je peux facilement ajouter d'autres fonctionnalités d'administration.

Par exemple, j'ai un nouveau client : avec une deuxième base, il faudrait d'abord créer l'utilisateur dans AD, puis le recréer dans cette nouvelle base pour lui allouer des ressources dans mon appli.

Par contre j'avoue que je ne comprends pas grand chose à la solution que tu proposes: un seul utilisateur ? pooling de quoi ?
Si tu pouvais me dire comment ça marche sur l'exemple suivant, ça serait parfait
Deux niveaux de connection : admin client qui peut allouer un numéro de tel à un employé, et employé qui peut seulement consulter son numéro.

[B.AF]

Ah comme ca oui ...

tu vas creer des groupes d'utilisateurs
Admin
Employes stresses
Managers tyranniques
Managers incompetents
Controleur de gestion
Interimaires renouvelles plus de 5 fois
etc,etc...

Chaque groupe peut etre hierarchiquement parent ou enfant d'un autre groupe.
Un parent peut acceder a l'enfant
Un enfant ne peut acceder au parent

Tu vas creer des Workgroups
Ces workgroups disposent des groupes associes
Le workgroup gere l'acces au domaine fonctionnel
En l'occurence :
Employe ne peut acceder a gestion client
Admin peut acceder a tous les clients de tous les groupes

Un utilisateur fait partie d'un groupe
Dans ce groupe, il peut lui meme etre parent ou enfant d'un autre utilisateur.

[cortex93]

Je reprends ce sujet car il correspond à mon problème aussi, et pense que la réponse n'était pas suffisante.

Mon souci étant :
Je dispose d'utilisateur et de groupes d'utilisateurs hiérarchiques, jusque là pas de souci.

Le souci étant que chacune des entités suivantes se voit attribuer des droits (lecture/écriture/création/....) sur des fonctionnalités et objets eux-mêmes regroupées hiérarchiquement.

Par exemple, je peux lire une fiche produit particulière dans le catalogue "bidon", modifier une autre fiche produit dans ce même catalogue, je peux rajouter des pages et y mettre des produits...
Mais ça pourrait être totalement différent dans un autre catalogue.


J'aimerais rester avec l'idée du membership provider et role provider .NET 2.0 mais si je base ma sécurité sur les roles, je vais me retrouver avec des roles comme Catalogue_bidon_Produit_livre_READER, Catalogue_bidon_Produit_livre_WRITER, Catalogue_bidon_Page_librairie_READER.

Ce qui n'est pas acceptable.

A contrario, je ne vois pas comment le framework me permet de gérer la sécurité autrement que par les roles (le sitemap ou meme les deny/allow dans le web.config n'accepte que des roles).

Si vous avez une idée quelconque, je suis preneur :p