Les objets peuvent avoir des autorisations multiples, mais seulement une autorisation pour chaque utilisateur ou groupe. Par exemple, une autorisation peut spécifier que GroupAdmin dispose du rôle Administrateur sur un objet. Une autre autorisation peut spécifier que GroupVMAdmin possède le rôle d'administrateur de machines virtuelles sur le même objet. Toutefois, le groupe GroupVMAdmin ne peut pas avoir une autre autorisation pour le même GroupVMAdmin sur cet objet.
Un objet enfant hérite des autorisations de son parent si la propriété de propagation du parent est définie sur true. Une autorisation qui est définie directement sur un objet enfant remplace l'autorisation dans l'objet parent. Reportez-vous à la section Exemple 2 : Autorisations d'enfant ignorant des autorisations de parent.
Si plusieurs rôles de groupe sont définis sur le même objet et qu'un utilisateur appartient à deux de ces groupes ou plus, deux situations sont possibles :
- Aucune autorisation n'est définie directement sur l'objet pour l'utilisateur. Dans ce cas, l'utilisateur obtient l'union des autorisations dont les groupes ont sur l'objet.
- Une autorisation est définie directement sur l'objet pour l'utilisateur. Dans ce cas, les autorisations de l'utilisateur sont prioritaires sur toutes les autorisations de groupe.
Exemple 1 : Héritage d'autorisations de plusieurs groupes
Cet exemple illustre comment un objet peut hériter d'autorisations multiples de groupes auxquels ont été accordés l'autorisation sur un objet parent.
Dans cet exemple, deux autorisations sont assignées sur le même objet pour deux groupes différents.
- PowerOnVMRole peut mettre des machines virtuelles sous tension.
- SnapShotRole peut prendre des snapshots de machines virtuelles.
- PowerOnVMRole est accordé à PowerOnVMGroup sur le dossier de VM, avec l'autorisation définie pour propager aux objets enfant.
- SnapShotRole est accordé à SnapShotGroup sur le dossier de VM, avec l'autorisation définie pour propager aux objets enfant.
- Aucun privilège spécifique n'est attribué à l'utilisateur 1.
L'utilisateur 1, qui appartient à la fois à PowerOnVMGroup et SnapShotGroup, se connecte. L'utilisateur 1 peut mettre sous tension et prendre des snapshots des VM A et B.
Exemple 2 : Autorisations d'enfant ignorant des autorisations de parent
Cet exemple illustre comment les autorisations attribuées sur un objet enfant peuvent remplacer les autorisations attribuées sur un objet parent. Vous pouvez utiliser ce comportement de non prise en compte pour limiter l'accès client à des zones spécifiques de l'inventaire.
Dans cet exemple, des autorisations sont définies sur deux objets différents pour deux groupes différents.
- PowerOnVMRole peut mettre des machines virtuelles sous tension.
- SnapShotRole peut prendre des snapshots de machines virtuelles.
- PowerOnVMRole est accordé à PowerOnVMGroup sur le dossier de VM, avec l'autorisation définie pour propager aux objets enfant.
- SnapShotRole est accordé à SnapShotGroup sur VM B.
L'utilisateur 1, qui appartient à la fois à PowerOnVMGroup et SnapShotGroup, se connecte. Puisque SnapShotRole est assigné à un point inférieur dans la hiérarchie que PowerOnVMRole, il ignore le PowerOnVMRole sur VM B. L'utilisateur 1 peut mettre sous tension VM A, mais ne peut pas prendre des snapshots. L'utilisateur 1 peut prendre des snapshots de VM B, mais ne peut pas les mettre sous tension.
Exemple 3 : Rôle d'utilisateur supprimant un rôle de groupe
Cet exemple illustre comment le rôle attribué directement à un utilisateur individuel remplace les privilèges associés à un rôle attribué à un groupe.
Dans cet exemple, les autorisations sont définies sur le même objet. Une autorisation associe un groupe à un rôle et l'autre l'autorisation associe un utilisateur individuel à un rôle. L'utilisateur est un membre du groupe.
- PowerOnVMRole peut mettre des machines virtuelles sous tension.
- PowerOnVMRole est accordé à PowerOnVMGroup sur le dossier de VM.
- On accorde à l'utilisateur 1 un rôle NoAccess sur le dossier de VM.
L'utilisateur 1, qui appartient à PowerOnVMGroup, se connecte. Le rôle NoAccess accordé à l'utilisateur 1 sur le dossier de VM remplace le rôle attribué au groupe. L'utilisateur 1 n'a pas accès au dossier de VM ou aux VM A et B. Les VM A et B ne sont pas visibles dans la hiérarchie de l'utilisateur 1.
