Java EE 6 groupes, des utilisateurs et des rôles -VS- rôles de Shiro, les utilisateurs et les autorisations

Question

Je suis en train de cartographier mentalement Java EE 6 concepts de sécurité de groupes, utilisateurs et rôles aux concepts de la Apache Shiro de rôles, utilisateurs et autorisations et je crois comprendre qu'ils sont incompatibles.

En lisant les Java EE 6 security tutorial, il semble que le modèle est trop restrictive: groupes sont configurés sur un serveur par serveur, et non par application, base qui nous laisse vraiment avec seulement deux concepts flexibles pour exprimer le mécanisme d'autorisation: utilisateurs et rôles, existant dans une relation 1-to-N simple. En revanche le modèle de Shiro des rôles, utilisateurs et autorisations est beaucoup plus dynamique car elle permet de coder en dur autorisations dans le code annoté et modifier la cartographie des rôles à autorisations lors de l'exécution que les choses changer ou que de nouveaux rôles sont introduits. Je ne vois pas comment on peut faire la même chose avec l'autorisation gérée par conteneur que dans le modèle Java EE 6.

Est-ce que je comprends bien? Parce que cela impliquerait que l'on ne peut pas vraiment aller très loin avec une autorisation gérée par conteneur.

Answer 1

Ils ne sont pas compatibles et je pense que les concepteurs de la sécurité Java EE se sont trompés car la terminologie semble être décalée par rapport à ROLES. Par expérience, je sais que fournir un contrôle d'accès basé sur ROLE (ce qui est suggéré dans leur documentation) ne fait que causer des problèmes plus tard quand vous voulez ouvrir une capacité à d'autres groupes/rôles. L'accès basé sur les autorisations, ramené aux rôles (ou groupes) semble fonctionner le mieux parce qu'il s'agit d'un exercice de remappage à un niveau abstrait plutôt que d'un recodage/ré-annotation.

Je peux voir comment vous seriez confus au sujet du modèle de sécurité Java EE. Je suggère de regarder de plus près Shiro et comment cela a modélisé la sécurité au niveau de l'application. Les Hazelwood, le créateur de Shiro, a écrit un blog about RBAC qui a beaucoup de sens pour les applications qui nécessitent un contrôle fin, même au niveau d'instance.