Je travaille sur une application PHP et j'aimerais ajouter un contrôle d'accès à certains de mes objets. Je n'ai pas marqué cette question en tant que PHP, car je pense que cette question n'est pas spécifique à la langue.
dire que j'ai une "classe de service" de nombreux services utilisent cette comme une base de base. Un pseudo exemple serait: plus tard dans la route, je veux ajouter un contrôle d'accès. L'exemple «GetCompanyinfobyID» est une opération «lecture», cela nécessiterait donc un privilège «Lire». À ce stade, je peux implémenter cela de la manière suivante: contre pour chaque option: Y a-t-il de meilleurs moyens d'aborder cela complètement?
3 Réponses :
Le modèle Java ee est à peu près sur les lignes de 2. Votre code est exécuté dans un "conteneur", vous indiquez au conteneur sur vos points d'entrée d'interface (URL pour les servlets, méthodes pour EJBS) et définissez les rôles pouvant utiliser ces points d'entrée. Un administrateur mappe les informations d'authentification (par exemple, les utilisateurs et les groupes LDAP) à des rôles spécifiques et au conteneur consultent la cartographie d'accéder à l'accès aux points d'entrée.
La clé ici est que le conteneur "sait" sur votre code, c'est efficacement un proxy assez intelligent.
En l'absence d'un conteneur, je regarderais l'approche proxy, peut-être utiliser une sorte de technique orientée forme.
Je pense que vous avez raison que l'option 3 est très fragile, trop de responsabilité sur les programmeurs clients.
Une autre solution pourrait être une petite variante de votre 1.
ex. de cette façon, vous ne mélangez pas de responsabilités et que vous pouvez toujours utiliser le polymorphisme Mes 2 cents
C'est plus ou moins ce que je m'appuyais.
J'y réfléchissais en fait à la mise en œuvre de ce modèle exact, mais cela me surprenne de voir le code réel que cela viole le principal du capital de la substitution de Liskov, car votre objet de votre entreprise ne jette pas une erreur d'accès, mais votre objet SafeCompanies fait, ce qui signifie que le code qui aurait pu s'appuyer sur sur ce comportement est maintenant cassé
dix ans plus tard ... Le monde a évolué un peu depuis et en particulier un tout nouveau paradigme a été mis en place: autorisation externe. Pour être juste, chaque cadre de développement a sa propre version de celui-ci (par exemple Cancancan dans la sécurité de rubis ou de printemps en Java ou à une autorisation basée sur les revendications en C #). L'autorisation extérieure vise à découpler la logique d'autorisation de la logique d'entreprise. L'idée est que les besoins d'autorisation pourraient évoluer indépendamment de la logique commerciale. Par exemple, votre logique d'entreprise fournit un accès aux comptes bancaires (affichage / modification / supprimer / transfert). La fonctionnalité est stable - elle ne changera pas dans un proche avenir. Toutefois, les besoins d'autorisation pourraient évoluer en raison de la législation (GDPR, une banque ouverte ...) ou des exigences différentes (délégation, parent-enfant, VIP ...) C'est pourquoi vous souhaitez maintenir l'autorisation Pour ce faire, il y a un modèle appelé contrôle d'accès basé sur l'attribut ( abac ) qui est une évolution / extension au contrôle d'accès plus connu basé sur le rôle ( rbac ). Dans RBAC, le contrôle d'accès est centré sur l'identité. Il est basé sur l'utilisateur, le rôle et le groupe (s) que l'utilisateur appartient. Ce n'est pas assez souvent. Dans ABAC, vous pouvez utiliser des attributs de l'utilisateur, des ressources, du contexte (heure) et de l'action. ABAC vous permet également d'écrire des stratégies en anglais nature en utilisant des langues politiques standardisées ( xacml ou alfa ou régo). Les plateformes cloud (AWS et Google) ont également mis en place leur propre langue (appelée Google IAM et AWS IAM respectivement).
Certains des avantages de l'ABAC sont les suivants:
Si vous voulez en savoir plus, consultez les pages Wikipedia pour ABAC et ALFA ainsi que Page de NIST sur ABAC .