Je n'aurais pas choisi de formuler le commentaire original de la manière dont il était libellé, mais cela identifie un problème potentiellement légitime.
Plus précisément, les préoccupations qui justifient la séparation sont l’ authentification contre l’ autorisation .
L'authentification fait référence au processus de connexion et d'obtention d'une identité. C’est ainsi que les systèmes savent qui vous êtes et sont utilisés pour des tâches telles que la personnalisation, la propriété d’objets, etc.
L'autorisation fait référence à ce que vous êtes autorisé à faire , et ceci (généralement) n'est pas déterminé par votre identité . Au lieu de cela, il est déterminé par certaines règles de sécurité, telles que les rôles ou les autorisations, qui ne se soucient pas de choses telles que votre nom ou votre adresse électronique.
Ces deux peuvent changer orthogonalement l'un à l'autre. Par exemple, vous pouvez modifier le modèle d'authentification en ajoutant des fournisseurs OpenID / OpenAuth. Vous pouvez également modifier la stratégie de sécurité en ajoutant un nouveau rôle ou en passant de RBAC à ABAC.
Si tout cela est classé dans une classe ou une abstraction, votre code de sécurité, qui est l’un de vos principaux outils d’ atténuation des risques , devient, paradoxalement, à haut risque.
J'ai travaillé avec des systèmes où authentification et autorisation étaient trop étroitement couplées. Dans un système, il y avait deux bases de données d'utilisateurs parallèles, chacune pour un type de "rôle". La personne ou l'équipe qui l'a conçu ne s'est apparemment jamais rendu compte qu'un seul utilisateur physique pouvait occuper les deux rôles, qu'il pouvait y avoir certaines actions communes à plusieurs rôles ou qu'il pouvait y avoir des problèmes de collisions d'ID utilisateur. C’est certes un exemple extrême, mais c’était / était incroyablement pénible de travailler avec.
Microsoft et Sun / Oracle (Java) font référence à l' ensemble des informations d'authentification et d'autorisation en tant que principal de sécurité . Ce n'est pas parfait, mais cela fonctionne raisonnablement bien. Dans .NET, par exemple, vous avez IPrincipal
, qui encapsule le IIdentity
- le premier étant une politique objet (autorisation) , alors que celle - ci est une identité (authentification). Vous pouvez raisonnablement remettre en question la décision de placer l'un à l' intérieur de l'autre, mais l'important est que la plupart du code que vous écrivez ne soit utilisé que pour l'une des abstractions, ce qui signifie qu'il est facile de tester et de refactoriser.
Il n'y a rien de mal avec un User.IsAdmin
champ ... à moins qu'il y ait aussi un User.Name
champ. Cela indiquerait que le concept "d'utilisateur" n'est pas correctement défini et qu'il s'agit malheureusement d'une erreur très courante parmi les développeurs qui sont un peu mouillés derrière les oreilles en matière de sécurité. Généralement, l' identité et la stratégie ne doivent être partagées que par l'ID utilisateur. Ce n'est pas une coïncidence si c'est exactement comment il est implémenté dans les modèles de sécurité Windows et * nix.
Il est tout à fait acceptable de créer des objets wrapper qui encapsulent à la fois l'identité et la stratégie. Par exemple, cela faciliterait la création d'un écran de tableau de bord dans lequel vous devez afficher un message "hello" en plus de divers widgets ou liens auxquels l'utilisateur actuel est autorisé à accéder. Tant que cette enveloppe juste enveloppe les informations d'identité et de la politique, et ne prétend pas posséder. En d'autres termes, tant que cela n'est pas présenté comme une racine globale .
Un modèle de sécurité simpliste semble toujours être une bonne idée lorsque vous concevez une nouvelle application, à cause de YAGNI et ainsi de suite, mais il finit presque toujours par vous revenir plus tard, car, surprise, de nouvelles fonctionnalités sont ajoutées!
Ainsi, si vous savez ce qui vous convient le mieux, vous allez séparer les informations d'authentification et d'autorisation. Même si "l'autorisation" est aussi simple qu'un indicateur "IsAdmin", vous serez toujours mieux s'il ne fait pas partie de la même classe ou du même tableau que les informations d'authentification. Ainsi, si et quand votre politique de sécurité doit change, vous n’avez pas besoin de faire de chirurgie reconstructive sur vos systèmes d’authentification qui fonctionne déjà bien.