J'ai mis en œuvre des modèles de sécurité à plusieurs reprises maintenant et j'ai également dû me concentrer sur ces concepts. Après l'avoir fait à plusieurs reprises, voici ma compréhension de ces concepts.
Quels sont les rôles
Rôle = L' union des utilisateurs et des autorisations.
D'une part, un rôle est une collection d'autorisations. J'aime l'appeler un profil d'autorisation. Lors de la définition d'un rôle, vous ajoutez essentiellement un ensemble d'autorisations à ce rôle, de sorte qu'en ce sens, un rôle est un profil d'autorisation.
D'un autre côté, un rôle est également une collection d'utilisateurs. Si j'ajoute Bob et Alice au rôle «Managers», alors «Managers» contient maintenant une collection de deux utilisateurs un peu comme un groupe.
La vérité est qu'un rôle est à la fois une collection d'utilisateurs et une collection d'autorisations réunies. Visuellement, cela peut être considéré comme un diagramme de Venn.
Qu'est-ce qu'un groupe
Groupe = Collection d'utilisateurs
Un «Groupe» est strictement un ensemble d'utilisateurs. La différence entre un groupe et un rôle est qu'un rôle a également une collection d'autorisations, mais un groupe n'a qu'une collection d'utilisateurs.
Qu'est-ce qu'une permission
Permission = ce qu'un sujet peut faire
Qu'est-ce qu'un ensemble d'autorisations
Ensemble d'autorisations = une collection d'autorisations
Dans un système RBAC robuste, les autorisations peuvent également être regroupées comme des utilisateurs. Alors que les groupes sont une collection d'utilisateurs uniquement, un ensemble d'autorisations est une collection d'autorisations uniquement. Cela permet à un administrateur d'ajouter des collections complètes d'autorisations aux rôles en une seule fois.
Comment les utilisateurs, les groupes, les rôles et les autorisations se réunissent
Dans un système RBAC robuste, les utilisateurs peuvent être ajoutés individuellement à un rôle pour créer la collection d'utilisateurs dans le rôle ou des groupes peuvent être ajoutés à un rôle pour ajouter une collection d'utilisateurs au rôle à la fois. Dans tous les cas, le rôle obtient sa collection d'utilisateurs en étant ajouté individuellement ou en ajoutant des groupes au rôle ou en ajoutant un mélange d'utilisateurs et de groupes au rôle. Les autorisations peuvent être considérées de la même manière.
Les autorisations peuvent être ajoutées individuellement aux rôles pour créer la collection d'autorisations à l'intérieur du rôle ou des ensembles d'autorisations peuvent être ajoutés à un rôle. Enfin, un mélange d'autorisations et d'ensembles d'autorisations peut être ajouté à un rôle. Dans tous les cas, le rôle obtient sa collection d'autorisations en étant ajouté individuellement ou en ajoutant des ensembles d'autorisations à un rôle.
Le but général des rôles est de marier les utilisateurs à des autorisations. Par conséquent, un rôle est l'union d'utilisateurs et d'autorisations.
Que sont les réclamations
Réclamation = Qu'est-ce qu'un sujet "est"
Les revendications ne sont PAS des autorisations. Comme indiqué dans les réponses précédentes, une allégation est ce qu'un sujet "n'est" pas ce qu'un sujet "peut faire".
Les revendications ne remplacent pas les rôles ou les autorisations, ce sont des informations supplémentaires que l'on peut utiliser pour prendre une décision d'autorisation.
Quand utiliser les revendications
J'ai trouvé que les réclamations étaient utiles lorsqu'une décision d'autorisation doit être prise lorsque l'utilisateur ne peut pas être ajouté à un rôle ou que la décision n'est pas basée sur l'association de l'utilisateur à l'autorisation. L'exemple d'un utilisateur Facebook en est la cause. Un utilisateur Facebook peut ne pas être quelqu'un qui est ajouté à un «rôle» ... il s'agit simplement d'un visiteur authentifié via Facebook. Bien que cela ne rentre pas parfaitement dans RBAC, il s'agit d'un élément d'information sur lequel prendre une décision d'autorisation.
@CodingSoft a utilisé la métaphore de la boîte de nuit dans une réponse précédente, que j'aimerais étendre. Dans cette réponse, le permis de conduire a été utilisé comme exemple contenant un ensemble de réclamations où la date de naissance représente l'une des réclamations et la valeur de la réclamation DateOfBirth est utilisée pour tester la règle d'autorisation. Le gouvernement qui a délivré le permis de conduire est l'autorité qui donne l'authenticité de la demande. Par conséquent, dans un scénario de boîte de nuit, le videur à la porte regarde le permis de conduire de la personne, s'assure qu'il a été délivré par une autorité de confiance en examinant s'il s'agit ou non d'une fausse pièce d'identité (c'est-à-dire qu'elle doit être une pièce d'identité valide émise par le gouvernement), examine ensuite la date de naissance (l'une des nombreuses revendications sur un permis de conduire), puis utilise cette valeur pour déterminer si la personne est assez âgée pour entrer dans le club. Si c'est le cas,
Maintenant, avec cette base à l'esprit, je voudrais maintenant étendre cela plus loin. Supposons que le bâtiment où se trouve la boîte de nuit contient des bureaux, des chambres, une cuisine, d'autres étages, des ascenseurs, un sous-sol, etc. où seuls les employés du club peuvent entrer. De plus, certains employés peuvent avoir accès à certains endroits que d'autres employés n'ont pas. Par exemple, un gestionnaire peut avoir accès à un étage de bureau au-dessus auquel les autres employés ne peuvent pas accéder. Dans ce cas, il y a deux rôles. Gestionnaire et employé.
Alors que l'accès des visiteurs à la zone de la boîte de nuit publique est autorisé par une seule réclamation comme expliqué ci-dessus, les employés doivent accéder par rôle à d'autres salles restreintes non publiques. Pour eux, un permis de conduire ne suffit pas. Ce dont ils ont besoin, c'est d'un badge d'employé qu'ils scannent pour entrer dans les portes. Quelque part, il y a un système RBAC qui accorde des badges dans le rôle de gestionnaire l'accès au dernier étage et des badges dans le rôle d'employé l'accès à d'autres salles.
Si, pour une raison quelconque, certaines salles doivent être ajoutées / supprimées par rôle, cela peut être fait à l'aide de RBAC, mais cela ne convient pas pour une réclamation.
Autorisations dans le logiciel
Le codage des rôles dans l'application est une mauvaise idée. Ce code fixe l'objectif du rôle dans l'application. Ce que l'application devrait avoir, ce sont simplement des autorisations qui agissent comme des indicateurs de fonctionnalité. Lorsque les indicateurs de fonctionnalité sont rendus accessibles par la configuration, les autorisations sont rendues accessibles par le contexte de sécurité de l'utilisateur qui est dérivé de la collection DISTINCT d'autorisations recueillies à partir de tous les rôles dans lesquels l'utilisateur a été placé. C'est ce que j'appelle les «autorisations effectives». L'application ne doit présenter qu'un menud'autorisations possibles sur des fonctionnalités / actions. Le système RBAC doit faire le travail d'associer ces autorisations aux utilisateurs via des rôles. De cette façon, il n'y a pas de codage en dur des rôles et la seule fois qu'une autorisation change, c'est lorsqu'elle est supprimée ou qu'une nouvelle est ajoutée. Une fois qu'une autorisation est ajoutée au logiciel, elle ne doit jamais être modifiée. Il ne doit être supprimé que lorsque cela est nécessaire (c'est-à-dire lorsqu'une fonctionnalité est interrompue dans une nouvelle version) et seules de nouvelles peuvent être ajoutées.
Une dernière note.
Accorder ou refuser
Un système RBAC robuste et même un système CBAC devraient faire la distinction entre les subventions et les refus.
L'ajout d'une autorisation à un rôle doit s'accompagner d'un GRANT ou d'un DENY. Lorsque les autorisations sont cochées, toutes les autorisations accordées doivent être ajoutées à la liste des utilisateurs des autorisations effectives. Ensuite, après tout ce qui est fait, une liste des autorisations REFUSÉES devrait amener le système à supprimer ces autorisations de la liste des autorisations effectives.
Cela permet aux administrateurs de "modifier" les autorisations finales d'un sujet. Il est préférable que les autorisations puissent également être ajoutées directement aux utilisateurs. De cette façon, vous pouvez ajouter un utilisateur à un rôle de gestionnaire et il aura accès à tout, mais peut-être souhaitez-vous REFUSER l'accès aux toilettes de la dame parce que l'utilisateur est un homme. Vous ajoutez donc l'utilisateur masculin au rôle de gestionnaire, et ajoutez une autorisation à l'objet Utilisateur avec REFUSER afin qu'il ne supprime que l'accès à la salle de cette dame.
En fait, ce serait un bon candidat pour une réclamation. Si l'utilisateur a une réclamation «sexe = homme», alors être dans le rôle de gestionnaire donne accès à toutes les chambres, mais les toilettes de la dame nécessitent également la réclamation gender = female et les toilettes pour hommes nécessitent la réclamation gender = male. De cette manière, il n'est pas nécessaire de configurer une autorisation DENY pour les utilisateurs masculins, car l'application de la revendication s'occupe de cela pour tout le monde avec une seule règle d'autorisation. Cependant, cela pourrait être fait de toute façon.
Le fait est qu'avec DENIAL of Permissions, cela facilite la gestion des rôles car des exceptions peuvent être implémentées.
Vous trouverez ci-dessous un diagramme que j'ai réalisé il y a longtemps et qui montre le modèle RBAC. Je n'ai pas de graphique pour les revendications, mais vous pouvez imaginer qu'il ne s'agit que d'attributs attachés aux utilisateurs où qu'ils se trouvent. De plus, le diagramme n'affiche pas les groupes (je dois le mettre à jour à un moment donné).
J'espère que ça aide.
Ceci est un diagramme du RBAC décrit ci-dessus
Mise à jour du 7 avril 2019
Sur la base des commentaires de @Brent (merci) ... a supprimé les références inutiles aux réponses précédentes et a expliqué la base originale de la métaphore du "night club" fournie par @CodingSoft afin de rendre cette réponse compréhensible sans avoir pour lire d'autres réponses.