Partager via


Relations entre les objets d'autorisation

Dernière modification : mercredi 14 avril 2010

S’applique à : SharePoint Foundation 2010

Dans cet article
Utilisateurs, groupes et entités de sécurité
Vue de niveau supérieur des relations entre les objets
Jetons d'utilisateurs et listes de contrôle d'accès

Un utilisateur individuel (SPUser) accède à un objet Microsoft SharePoint Foundation directement via une affectation de rôle, ou indirectement via l’appartenance à un groupe de domaines ou à un groupe SharePoint (SPGroup) possédant une affectation de rôle. Dans une affectation de rôle directe, l’utilisateur est l’entité de sécurité (SPPrincipal). Dans une affectation à un groupe de domaines ou un groupe SharePoint, le groupe de domaines ou le groupe SharePoint est l’entité de sécurité.

Utilisateurs, groupes et entités de sécurité

SharePoint Foundation prend en charge les utilisateurs Windows (par exemple, DOMAINE\Alias_utilisateur) et les utilisateurs externes (par le biais de l’authentification enfichable). L’identité de l’utilisateur est gérée par le système de gestion des identités (notamment, le service d’annuaire Active Directory). Le profil utilisateur (qui inclut le nom complet, l’adresse de messagerie et d’autres informations de l’utilisateur) est étendu au niveau collection de sites. La modification d’un nom complet affecte l’ensemble de la collection de sites.

Un groupe est une collection d’utilisateurs par le biais duquel SharePoint Foundation gère la sécurité. La gestion basée sur les utilisateurs est facile pour les sites simples, mais devient plus complexe au fur et à mesure que le nombre de ressources sécurisées de manière unique augmente. Par exemple, un utilisateur peut avoir le rôle Contribute pour la liste 1, le rôle Read pour la liste 2 et le rôle Design pour la liste 3. Ce modèle n’est pas adapté s’il existe, par exemple, 50 000 utilisateurs, ce qui aurait pour résultat des listes de contrôle d’accès contenant 50 000 entrées de contrôle d’accès sur chaque objet sécurisé de façon unique.

Les groupes offrent une réponse à la facilité de gestion et aux problèmes d’échelle de la gestion des autorisations basées sur les utilisateurs. La gestion basée sur les groupes peut être plus abstraite ou plus difficile à concevoir, mais elle facilite la gestion des sites complexes avec plusieurs objets sécurisés de façon unique, par exemple, lors de l’ajout d’un utilisateur à un groupe auquel a déjà été accordé le rôle approprié sur différents objets dans le système. Le contrôle des autorisations pour les groupes est plus facile à ajuster car un plus petit nombre d’entrées de contrôle d’accès doivent être stockées.

SharePoint Foundation prend en charge deux types de groupes : les groupes de domaines et les groupes SharePoint. Les groupes de domaines restent hors du contrôle deSharePoint Foundation ; les utilisateurs ne peuvent pas utiliser SharePoint Foundation pour définir, parcourir ou modifier l’appartenance au groupe de domaines. Les groupes SharePoint ont une étendue limitée au niveau collection de sites, et ils ne peuvent être utilisés que dans la collection de sites. Les groupes de domaines peuvent être utilisés n’importe où dans l’étendue du service d’annuaire Active Directory.

Une entité de sécurité est un utilisateur ou groupe qui est utilisé pour contrôler la sécurité. Si vous ajoutez un utilisateur à un site, l’utilisateur est l’entité de sécurité, mais si vous ajoutez un groupe au site, le groupe est l’entité de sécurité. La clé pour la sécurité de la mise à l’échelle dans SharePoint Foundation consiste à conserver un nombre d’entités de sécurité par étendue raisonnable. À l’aide de groupes, un petit nombre d’entités de sécurité peut servir à accorder l’accès à un beaucoup plus grand nombre d’utilisateurs.

Vue de niveau supérieur des relations entre les objets

La figure 1 affiche une vue de niveau supérieur du système de gestion de la sécurité SharePoint Foundation dans un diagramme de base de données logique. Chaque case représente un objet de sécurité dans le système. Les lignes représentent des relations entre les objets. La notation 1 et N représente le type de relation. La figure illustre la structure des données d’autorisation dans un jeton utilisateur et une liste de contrôle d’accès.

Figure 1. Relations de l’objet d’autorisation

Relations de l’objet d’autorisation

Une étendue représente un objet ou un ensemble d’objets sécurisés de façon unique. Vous pouvez définir une étendue au niveau site, liste, dossier ou élément.

Les utilisateurs et les groupes ont une relation plusieurs à plusieurs (N à N). Chaque utilisateur (SPUser) peut être un membre de plusieurs groupes, et chaque groupe (SPGroup) peut contenir plusieurs utilisateurs.

Les droits et les définitions de rôles ont également une relation plusieurs à plusieurs (N à N). Chaque droit SPBasePermissions) peut faire partie de plusieurs définitions de rôles. Par exemple, le droit Insert List Items est inclus dans les définitions de rôles Contributor, Designer et Administrator. Chaque définition de rôle SPRoleDefinition) peut également contenir plusieurs droits. Par exemple, Contributor inclut le droit d’insérer, mettre à jour et supprimer des éléments de liste.

Les définitions de rôles et les affectations de rôles (SPRoleAssignment) ont une relation un-à-plusieurs (1 à N). Chaque définition de rôle est utilisée dans plusieurs affectations de rôles. Les lecteurs de la liste 1 et ceux de la liste 2 peuvent être différents, mais leurs affectations de rôles peuvent partager une seule définition de rôle : Reader.

Les utilisateurs ou groupes et les affectations de rôles ont une relation plusieurs à plusieurs (N à N). Chaque utilisateur ou groupe peut être membre de plusieurs affectations de rôles sur un objet donné. Par exemple, un utilisateur peut avoir le rôle Designer et le rôle Administrator sur le même objet.

Les étendues et les affectations de rôles ont une relation un-à-plusieurs (1 à N). Chaque étendue a plusieurs affectations de rôles, mais chaque attribution de rôle possède une seule étendue. Par exemple, un utilisateur peut être un lecteur dans la liste des événements et un autre utilisateur peut être un collaborateur dans la liste des événements, mais aucune de ces affectations de rôles ne s’applique à la liste Annonces. La seule façon pour les deux listes de partager la même attribution de rôle consiste à hériter de leurs autorisations à partir du conteneur parent, auquel cas l’étendue de sécurité est le conteneur, et non pas les deux listes.

Jetons d'utilisateurs et listes de contrôle d'accès

Pour effectuer la vérification des autorisations plus rapidement, SharePoint Foundation implémente des jetons utilisateur et des listes de contrôle d’accès dans son modèle de sécurité. Le jeton de l’utilisateur identifie le processus d’authentification appliqué à un utilisateur. Un utilisateur Windows dispose d’un jeton complexe : une chaîne unique pour l’utilisateur (SID, Security Identifier) et une liste de tous les groupes de domaines Windows pour l’utilisateur, par exemple, DOMAINE \Service 15688. Un utilisateur qui n’a pas l’authentification Windows peut avoir un jeton très simple avec une chaîne unique pour le nom de l’utilisateur, ou un jeton complexe avec l’appartenance au groupe/rôle simplement telle qu’exprimée dans l’authentification Windows. L’appartenance de groupe pour chaque utilisateur est exprimée par un jeton utilisateur de sorte que, en lisant le jeton de l’utilisateur, SharePoint Foundation identifie tous les groupes de l’utilisateur actuel.

Une liste de contrôle d’accès est un objet binaire qui détermine les droits des utilisateurs et groupes sur un objet donné. Une liste de contrôle d’accès se compose de plusieurs entrées de contrôle d’accès, chaque entité de sécurité (utilisateur ou groupe) étant une entrée de contrôle d’accès dans la liste de contrôle d’accès. Les droits, les définitions de rôles et les attributions de rôles sont structurés dans une liste de contrôle d’accès pour chaque étendue, afin que SharePoint Foundation sache ce que chaque utilisateur ou groupe est autorisé à faire dans l’étendue donnée.

Voir aussi

Concepts

Identité basée sur des revendications SharePoint