Cette documentation est archivée et n’est pas conservée.

Modifications dans le modèle objet d'autorisation

Windows SharePoint Services 3

Dans Windows SharePoint Services 3.0 toutes les étendues d'objet partagent la même expérience de gestion des autorisations de base. Contrairement à Windows SharePoint Services 2.0, Windows SharePoint Services 3.0 gère les autorisations par le biais des définitions de rôles, et non pas des groupes de sites, ce qui permet une expérience cohérente au niveau des listes, dossiers et éléments. Dans Windows SharePoint Services 3.0, les groupes de sites précédents sont mappés sur des définitions de rôles.

Groupes de sites

Le concept de groupe de sites est désapprouvé dans Windows SharePoint Services 3.0, et le concept de groupe intersite suppose un rôle plus important : les groupes de domaines, par exemple, peuvent maintenant être membres des groupes intersites. Cela n'était pas autorisé dans Windows SharePoint Services 2.0 en raison du problème potentiel lié à l'imbrication des groupes qui en résulte, par exemple, lorsqu'un utilisateur est membre d'un groupe de domaines, d'un groupe intersite et d'un groupe de sites.

Modèle objet

Windows SharePoint Services 3.0 implémente de nouveaux types dans son modèle objet pour prendre en charge le nouveau modèle de sécurité. Les objets de sécurité suivants utilisés dans la version précédente sont obsolètes mais continuent à fonctionner pour des raisons de compatibilité descendante :

Pour affecter les utilisateurs à des rôles, utilisez plutôt les membres des nouvelles classes Microsoft.SharePoint.SPRoleAssignment et Microsoft.SharePoint.SPRoleAssignmentCollection. La nouvelle énumération Microsoft.SharePoint.SPBasePermisssions inclut de nouvelles autorisations, en plus des nombreuses autorisations d'ancienne génération qui mappent vers les mêmes valeurs de constante en tant qu'autorisations précédentes dans SPRights. Le nouveau concept de groupe SharePoint mappe vers les objets SPGroup et SPGroupCollection existants qui représentaient des groupes intersites.

La sécurité au niveau du site Web est facile à mapper entre Windows SharePoint Services 2.0 et Windows SharePoint Services 3.0, car un groupe de sites 2.0 devient un groupe de site et une définition de rôle 3.0. Windows SharePoint Services 2.0 ne prenait pas en charge l'octroi direct des droits aux utilisateurs au niveau du site Web, et par conséquent l'ancien modèle objet mappe directement à l'autre

La mise à niveau de la sécurité au niveau de la liste de la version 2.0 vers la version 3.0 s'effectue dans l'ordre suivant :

  1. Des autorisations d'un rôle par défaut sont affectées aux utilisateurs et groupes. Après la mise à niveau, l'utilisateur a le même rôle avec les mappages suivants :

    • Administrateur — Contrôle total

    • Concepteur Web — Conception

    • Collaborateur — Collaboration

    • Lecteur — Lecture

    • Invité — Accès limité

  2. Des autorisations d'un rôle personnalisé sont affectées aux utilisateurs et groupes. Après la mise à niveau, les utilisateurs ont le même rôle.

  3. Des droits de liste spécifiques sont affectés aux utilisateurs et groupes. Après la mise à niveau, Windows SharePoint Services génère de nouveaux rôles avec les droits de liste appropriés et assigne le nouveau rôle aux utilisateurs.

Rôles de stratégie

Rôles invité

Le concept d'un rôle Invité a été introduit dans Windows SharePoint Services 2.0 pour prendre en charge les ressources partagées au sein de la plateforme. Par exemple, le thème et la structure de navigation du site Web doivent être utilisés pour restituer la page pour un affichage de liste. Ce concept continue dans Windows SharePoint Services 3.0 et est étendu pour inclure des autorisations au niveau des listes et dossiers.

Le modèle objet Windows SharePoint Services 3.0 continue d'appeler ce rôle Guest pour la compatibilité sémantique avec le modèle objet précédent, même si dans l'interface utilisateur le rôle s'appelle désormais Accès limité.

Extensions de dossier et d'élément

Lorsque des autorisations sur un dossier sont accordées à un utilisateur, elles sont aussi accordées au rôle Guest sur la liste parente de ce dossier et sur le site Web parent de cette liste, sur chaque étendue sécurisée de manière unique jusqu'au premier site Web ancêtre. Cela s'applique aussi aux éléments de liste : l'octroi d'autorisations à un utilisateur sur un élément lui accorde également le rôle Guest sur tous les dossiers parents, listes et sites Web jusqu'au premier site Web ancêtre.

Suppression d'utilisateurs

Supprimer un utilisateur d'une étendue supprime également cet utilisateur de toutes les étendues sécurisées de manière unique en dessous de l'étendue actuelle. Par exemple, supprimer un utilisateur à partir d'un site Web supprime aussi cet utilisateur des listes sécurisées de manière unique dans le site.

La seule solution pour supprimer un utilisateur de toutes les étendues consiste à supprimer cet utilisateur de la collection de sites, ce qui le supprime de tous les rôles dans toutes les étendues de la collection de sites.

Afficher: