Autorisation, utilisateurs et groupes

Article
09/24/2014

Dernière modification : mercredi 14 avril 2010

S’applique à : SharePoint Foundation 2010

Dans Microsoft SharePoint Foundation, l’accès aux sites Web, listes, dossiers et éléments de liste est contrôlé par un système d’appartenance à des rôles dans lequel les utilisateurs sont affectés à des rôles qui leur donnent accès aux objets SharePoint Foundation.

Pour donner l’accès à un objet à un utilisateur, vous pouvez l’ajouter à un groupe possédant déjà des autorisations sur l’objet ou vous pouvez créer un objet d’affectation de rôle, définir l’utilisateur pour l’affectation de rôle, lier l’affectation de rôle à la définition de rôle appropriée contenant les autorisations de base (facultatif) et ajouter l’affectation à la collection des affectations de rôle de l’élément de liste, du dossier, de la liste ou du site Web. Si vous ne liez pas l’affectation de rôle à une définition de rôle lorsque vous affectez un rôle à un utilisateur, ce dernier ne reçoit aucune autorisation.

Plusieurs méthodes permettent de contrôler l’accès aux objets SharePoint Foundation :

Les objets peuvent utiliser les mêmes autorisations que le site Web, la liste ou le dossier parent (et hériter des rôles et des utilisateurs disponibles sur l’objet parent). Ils peuvent aussi utiliser des autorisations uniques.
Les sites, listes, dossiers et éléments de liste fournissent des collections d’affectations de rôles, ce qui permet une gestion précise de l’accès des utilisateurs aux objets.
Les groupes sont composés d’utilisateurs et peuvent être ou ne pas être affectés à des rôles. SharePoint Foundation comprend les trois groupes suivants par défaut :
- owners (administrateur)
- members (collaborateur)
- visitors (lecteur)

Lorsque vous créez un site Web avec des autorisations uniques par le biais de l'interface utilisateur, vous êtes dirigé vers une page où vous pouvez affecter des utilisateurs à ces groupes dans le cadre de la mise en service du site.

L'accès anonyme permet aux utilisateurs de participer de manière anonyme à des listes et des enquêtes, ou d'afficher des pages de façon anonyme. Vous pouvez également accorder l'accès à « Tous les utilisateurs authentifiés » pour autoriser tous les membres de votre domaine à accéder à un site Web sans avoir à activer l'accès anonyme.
Les droits de création de site (CreateSSCSite et ManageSubwebs) contrôlent la possibilité pour les utilisateurs de créer des sites Web de niveau supérieur, des sous-sites ou des espaces de travail.

Les utilisateurs deviennent membres d’un objet SharePoint soit indirectement via un groupe qui a une affectation de rôle, ou directement via une affectation de rôle. Les utilisateurs peuvent également être membres d’un groupe de domaine Microsoft Windows NT qui est ajouté à un groupe ou à un rôle. Une définition de rôle associe un utilisateur ou groupe à un seul droit ou un ensemble de droits correspondant à des valeurs de l’énumération Microsoft.SharePoint.SPBasePermissions. Chaque utilisateur ou groupe a un ID de membre unique.

Vous pouvez utiliser le modèle objet pour créer ou modifier les affectations et définitions de rôles différemment par rapport à la fonctionnalité du fichier addrole.aspx et du fichier editrole.aspx. À l’inverse des pages présentées dans l’interface utilisateur, le modèle objet n’applique aucune dépendance de droits. Vous pouvez donc créer une définition de rôle avec une combinaison arbitraire de droits. Toutefois, soyez très attentif lorsque vous utilisez le modèle objet pour personnaliser les définitions de rôles et les autorisations, car une définition de rôle mal conçue et des droits octroyés de manière inappropriée peuvent conduire à une expérience utilisateur déplaisante.

Pour plus d’informations sur les droits SharePoint Foundation, voir SPBasePermissions.

Stratégie de sécurité

Une stratégie de sécurité permet d’appliquer une sécurité uniforme à travers toutes les collections de sites d’une application Web (serveur virtuel). À travers une stratégie, vous pouvez affecter un rôle, ou une collection de droits, à des utilisateurs SharePoint Foundation individuels et à des groupes de domaine par le biais de l’authentification Windows ou de systèmes d’authentification enfichables, mais pas à des groupes SharePoint. Chaque entrée de la stratégie spécifie les droits d’un utilisateur ou groupe de l’application Web.

La stratégie est définie au niveau de la zone ou au niveau de l’application Web logique. Par exemple, un utilisateur peut avoir plusieurs stratégies sur https://Server et http://Server.extranet.microsoft.com, même si les deux applications Web ont le même contenu.

Les droits peuvent être accordés ou refusés par le biais de la stratégie. Le fait d’accorder un droit donne ce droit à l’utilisateur ou au groupe sur tous les objets sécurisés de l’application Web indépendamment des autorisations locales sur l’objet. Le fait de refuser un droit est prioritaire sur le fait de l’accorder, bloquant activement ce droit pour l’utilisateur ou le groupe sur tous les objets sécurisés de l’application Web. En refusant tout accès à un utilisateur, vous l’empêchez d’accéder à tout le contenu, même s’il dispose d’autorisations explicites sur un contenu spécifique : la stratégie remplace les autorisations de niveau site.

Dans les rôles de stratégie, les utilisateurs et les groupes sont identifiés par le biais de leur identifiant de sécurité (SID) et leur nom d’utilisateur ou de connexion. L’application d’un rôle de stratégie est similaire à la gestion des autorisations pour un site Web, une liste, un dossier ou un document. Vous ajoutez des utilisateurs ou des groupes et vous les affectez à une ou plusieurs définitions de rôles. Chaque application Web a ses propres rôles de stratégie. Une autre différence entre les rôles de stratégie et la gestion des autorisations réside dans le fait que les administrateurs centraux peuvent refuser un droit à un utilisateur dans l’ensemble d’une application Web.

Notes

Les rôles de stratégie de l'Administration centrale diffèrent des définitions de rôles d'une collection de sites.