Discussion :

[Droide63000]

Bonjour à tous,
Depuis quelques semaines, je me suis mis sur le framework symfony2 et il y a une chose que j'aimerai faire mais sur laquelle je bloque.
Pour la gestion des mes utilisateurs, j'utilise le FOSUserBundle. La, il n'y a pas trop de souci, je lu la documentation et j'ai réussi à le mettre en place

Par contre, j'aimerai maintenant créer des groupes utilisateurs pouvant avoir des permissions comme par exemple (ARTICLE_CREATE, ARTICLE_READ, ARTICLE_UPDATE, COMMENTAIRE_READ, COMMENTAIRE_CREATE,etc...). Et la problème, je ne vois pas comment faire cela (surtout au niveau de isGranted).

J'ai créé mon entité groupe qui extends de BaseGroup mais lui contient des rôles définit dans la config YML(ROLE_ADMIN, ROLE_USER,...)..

Je ne sais pas si je suis très claire mais merci d'avance pour l'aide que vous allez pouvoir m'apporter

[Nico_F]

Salut.

Il ne faut pas chercher à faire des groupes correspondant à chacune de tes actions, mais plutôt définir quel groupe est autorisé à y accéder.
Avoir un User qui possède 50 rôles est moins intéressant que d'avoir une route qui autorise un ou deux groupes de sécurité maximum.
De manière générale, tu ne devrais pas avoir besoin d'avoir beaucoup de groupes de sécurité : un groupe "User", "Admin", "Super admin" potentiellement deux ou trois autres groupes propres à tes problématiques métier mais rarement plus.

Pour chaque route/action, tu auras la possibilité de gérer l'accès à un ou plusieurs groupes.
Typiquement, une action read() sera accessible à tout le monde ou presque tandis qu'une action de modification ou de suppression ne sera accessible qu'à un rôle admin ou superadmin. (par exemple)

Je ne sais pas comment fonctionne le FosUserBundle, ni ce qu'il offre comme fonctionnalité supplémentaire, mais dans ton cas précis, rien que Symfony ne soit capable de faire seul.
La documentation de Symfony est très claire concernant la sécurité et la gestion des accès et des rôles : http://symfony.com/fr/doc/current/book/security.html

Bonne lecture.

[Droide63000]

Ok mais j'aimerais bien ne pas faire l'autorisation suivant les groupes mais suivant des credentials que contiendrais ces groupes (ENTITEA_CREATE, ENTITEA_UPDATE,etc,etcetc)..
Il me semble que c'est ce que faisais symfony1.4 avec sfGuardUser, sfGuardGroup et sfGuardPermissions non?

[gototog]

Quel est ton scenario métier qu'on puisse te répondre d'une manière plus concrète?

[Droide63000]

J'ai des utilisateurs qui doivent se connecter à une application (username et password) afin de pouvoir l'utiliser.

Dans cette application, j'ai par exemple une entité "Banque" qui va contenir une pk, un libelle, un code banque etc etc...
J'ai aussi un controller BanqueController qui va avoir différentes opération comme indexAction (permettant de lister les banques), addAction (permettant d'ajouter une banque), removeAction (permettant de supprimer une banque)...

Maintenant, tout les utilisateurs n'ont pas le droit de modifier, ajouter, créer ou supprimer une banque.
Du coup oui, je pourrai travailler avec les rôles mais pour ma part, je trouve que la gestion des rôles n'est pas assez poussée.

Ainsi, j'aimerai que l'utilisateur A qui se connecte et qui a la permission BANQUE_CREATE puisse ajouter une banque mais que l'utilisateur B a qui on a enlevé cette permissions ne le puisse pas. Mais rien ne lui empêche de modifier, supprimer une banque si il a les bonne permissions (BANQUE_EDIT et BANQUE_DELETE)
Et donc en clair, on aurait autant de permission que d'action..

Maintenant on mets les permissions au niveau des groupes comme par exemple groupe1, groupe2 et chaque utilisateur possede un ou plusieurs groupes et donc imaginons l'edition d'un groupe :


GROUP1 : Groupe utilisateur A

Entité	Create	Read	Update	Delete
Banque	Oui	Oui	Oui	Oui

GROUP2 : Groupe utilisateur B

Entité	Create	Read	Update	Delete
Banque	Non	Oui	Oui	Oui

Je suis peut-être pas assez clair.. et je m'en excuse

[damiensan]

Bonjour,

Si tu utilises FOSUserBundle, les groupes peuvent avoir des permissions de la même manière qu'un utilisateur peut avoir une ou des permissions.
Ces permissions sont configurables dans le fichier de sécurité.

Je suis d'accord avec toi le système de sécurité et de rôles me paraît affreux. C'est pourquoi j'ai créé une surcouche pour adapter le composant de sécurité à mes besoins.

Je voulais faire comme toi. Des utilisateurs liés à des groupes et ces groupes ayant des permissions liées à des routes.

Contrairement à ce que dit Nico_F :

De manière générale, tu ne devrais pas avoir besoin d'avoir beaucoup de groupes de sécurité : un groupe "User", "Admin", "Super admin" potentiellement deux ou trois autres groupes propres à tes problématiques métier mais rarement plus.

J'ai besoin de très nombreux groupes, car mon site ne se résume pas à un blog ou un petit site entre amis, mais à une application professionnelle. Du coup les utilisateurs sont très nombreux, les groupes également, ainsi que les permissions.

Pour résoudre mon problème. Cela a été relativement simple.

1 / J'ai créé une tâche qui liste l'ensemble des routes de mon appli back office (elles sont toutes préfixées par admin_) et qui les stocke en base dans une table permission. Par défaut je considère que toutes mes routes sont sécurisées (flag en base) mais ceci est configurable

2 / J'ai créé trois modules BO pour gérer les utilisateurs, les groupes et les permissions avec sonata. Relation n-n entre user et groupes et relation n-n entra groupe et permission.

3 / J'ai créé un controlerListener qui écoute l'évent onKernelRequest. Dans ce controller je vérifie que ma route est back ou front, si back je vérifie en base si elle est sécurisée, si elle est sécurisée je vérifie dans les groupes de mon utilisateurs si la permission est présente, sinon je lance une exception AccesDenied. J'ai modifié le template de l'erreur 403 en spécifiant que "les droits sont insuffisant, contactez le service IT blablabla…"

Et voila. Je t'omets les différents détails d'implémentation. Mais voici les grandes lignes.

De cette façon je contrôle tous mes utilisateurs, mes groupes et mes permissions dans mon interface BO et je n'ai pas besoin de mettre à jour le fichier security.yml avec 450 000 lignes de rôles

[Nico_F]

Il y a quelque chose qui m'échappe dans vos réflexions : pour vous quelle est la différence entre un rôle et un groupe ?

Dans ce que tu décris je ne vois pas dans quel cas la gestion des rôles n'est pas assez poussée. Est-ce qu'elle doit être managée par un user dans le BO par exemple (stocké en BDD) ou est-ce que c'est fixe et que ça n'a pas lieu de changer (les rôles sont définis en dur dans le code) ?

Globalement ce que tu appelles groupes, chez moi il s'agit des rôles : et je n'ai aucun problème pour définir les accès de chacun aux routes.

Prend le problème comme tu le prendrais dans la vie de tous les jours. Dans une société les commerciaux accèdent au commerce, les comptables accèdent à la compta etc.
Je simplifie mais : ton contrôleur c'est Comptabilité :
- tu donnes un accès aux users du groupe 'comptable' ?
- ou tu donnes à tous les users qui font de la compta la liste de toutes les actions qu'ils pourront faire ?


En faisant un groupe par action, tu te retrouve avec un user qui a une liste de 30, 40, 50 actions autorisées. Au lieu de posséder un ou deux groupes et ses groupes sont autorisés par 30, 40 ou 50 actions. Donc oui je veux bien admettre que dans certains cas tu peux avoir plus que 3 ou 4 groupes, mais même dans une application professionnelle (je dirais même SURTOUT dans une application professionnelle) les gens ont un rôle bien précis. Et il n'y a à priori pas de raison pour que deux personnes n'ayant pas la même fonction n'aient pas les mêmes accès.

Donc même si tu faisais un CRM pour une boite de 10000 users tu auras toujours plus d'actions que de groupes, et donc de rôles.

De cette façon je contrôle tous mes utilisateurs, mes groupes et mes permissions dans mon interface BO et je n'ai pas besoin de mettre à jour le fichier security.yml avec 450 000 lignes de rôles

D'autre part, configurer les autorisations au niveau même de la définition de la route ou du contrôleur (via des annotations par exemple) évite ce genre de souci.

[damiensan]

Bonjour,

Pour faire simple un rôle = une permission -> une route. exemple: createProductAction, setProductOnlineAction.

Un groupe = un rassemblement de permissions sous un nom. Exemple: Compta, Compta superviseur, marketing, stagiaire marketing …

Je définis dans mon interface que les stagiaires marketing peuvent faire telles et telles actions. Puis j'associe x utilisateurs à ce groupes et peut être n utilisateurs à ce groupe plus un autre.
Et si je veux que tous les utilisateurs stagiaire marketing aient une autre permission, je l'ajoute dans le group et hop c'est fini.

D'autre part, configurer les autorisations au niveau même de la définition de la route ou du contrôleur (via des annotations par exemple) évite ce genre de souci.

C'est bien ça le problème, je veux pouvoir modifier mes groupes et mes permissions sans avoir à faire de mise en prod. Utiliser les annotations n'est absolument pas flexible. Une administration en BDD l'est beaucoup plus.

Si tu veux modifier 25 actions pour les attribuer à 12 nouveaux "groupes" comment fais-tu ?