Autorisation du service Business Data Connectivity

Dernière modification : jeudi 15 avril 2010

S’applique à : SharePoint Server 2010

Dans cet article
Autorisation principale
Autorisation de couche intermédiaire
Autorisation principale avec le filtre UserContextFilter
Objets de métadonnées à accès contrôlé et objets de métadonnées sécurisables individuellement
Résumé des droits

Vous pouvez utiliser l’un des deux modèles d’autorisation pour contrôler l’accès utilisateur aux données gérées par Microsoft Business Connectivity Services (BCS) : l’autorisation principale ou l’autorisation de couche intermédiaire.

Autorisation principale

Si votre serveur principal peut effectuer des autorisations par utilisateur, vous pouvez alors utiliser les autorisations principales pour contrôler les accès utilisateur. Vous pouvez utiliser l'autorisation principale dans les situations suivantes :

• Vous utilisez le modèle d’emprunt d’identité et de délégation pour l’authentification et l’autorisation se fait par utilisateur sur le serveur principal. Dans le modèle d’emprunt d’identité et de délégation, le client délègue l’authentification à la couche intermédiaire, qui emprunte l’identité du client et s’authentifie sur le serveur principal au nom du client. Toutefois, si le serveur principal ne prend pas en charge l’autorisation par utilisateur, vous serez peut-être amené à utiliser l’un des autres systèmes d’autorisation décrits dans la présente rubrique.

• Le serveur principal prend en charge l'autorisation par utilisateur et vous utilisez l'autorisation au niveau application, en passant le nom d'utilisateur dans le filtre Username.

• Le serveur principal offre le regroupement de connexions ou d'autres avantages en termes de performances.

Autorisation de couche intermédiaire

Dans le modèle d'authentification du sous-système approuvé, la couche intermédiaire s'authentifie sur le serveur principal en tant qu'identité fixe et le serveur principal ne connaît jamais l'identité de l'utilisateur. Par conséquent, si vous utilisez ce modèle d'authentification, vous ne pouvez pas utiliser l'autorisation principale, même si le serveur principal prend en charge l'autorisation par utilisateur, car le serveur ne peut pas accorder d'autorisation à chaque utilisateur.

Dans de tels cas, utilisez plutôt l’autorisation de couche intermédiaire du Service BDC (Business Data Connectivity). Le service BDC est conçu pour les autorisations par utilisateur dans la couche intermédiaire. Ce modèle d’autorisation présente les avantages suivants :

• regroupement de connexions de bases de données ;

• modèle unique pour l’autorisation ;

• prise en charge de scénarios dans lesquels il n’existe pas d’autorisation par utilisateur au niveau du serveur principal ;

• un contrôle d’accès granulaire. Le service BDC permet de définir les listes de contrôle d’accès aux niveaux suivants :

  • MetadataCatalog   Il s’agit de l’objet de niveau supérieur dans le service BDC, qui contrôle qui peut importer ou exporter des modèles dans le service BDC

  • LobSystem

  • Entity

  • Method

  • MethodInstance

  Par ailleurs, vous pouvez obtenir différentes vues des entités dans le service BDC, et par conséquent contrôler les champs qu’un utilisateur peut visualiser.

Autorisation principale avec le filtre UserContextFilter

Le filtre UserContextFilter indique au service BDC d’ajouter le nom de l’utilisateur actif dans l’appel de la méthode principale. La méthode principale peut ensuite utiliser le nom d’utilisateur pour vérifier l’accès de l’utilisateur ou limiter les instances d’entités renvoyées à partir du serveur principal par le contexte de l’utilisateur actif.

Cela s’avère particulièrement utile lorsque des applications principales ne possèdent pas d’informations d’autorisation ou ne les utilisent pas pour des raisons de licence ou de regroupement de connexions. Dans ces cas-là, elles peuvent utiliser un compte de groupe pour l’authentification et utiliser le nom d’utilisateur transmis afin de déterminer et de contrôler l’accès aux données.

Un autre scénario d’utilisation de filtre UserContext est possible si un auteur de métadonnées crée des métadonnées qui prennent un nom d’utilisateur comme filtre contrôlable par l’utilisateur et renvoient des données personnelles sensibles. Dans ce cas, un utilisateur peut être amené à voir les données d’un autre utilisateur. Pour éviter cela, vous pouvez utiliser le filtre UserContext pour passer le nom d’utilisateur dans l’appel de la méthode.

Pour les utilisateurs de Windows, le service BDC passe la propriété System.Security.Principal.WindowsPrincipal.Identity au format nomdomaine\nomutilisateur.

Objets de métadonnées à accès contrôlé et objets de métadonnées sécurisables individuellement

Dans la hiérarchie d’objets de métadonnées du service BDC, chaque objet (Application, Entity, Method, MethodInstance, Parameter, TypeDescriptor, et ainsi de suite.) possède une liste de contrôle d’accès qui spécifie les entités de sécurité ayant des droits sur l’objet. Parmi les 13 objets de métadonnées, seuls LobSystem, Entity, Method et MethodInstance possèdent leur propre liste de contrôle d’accès contrôlable. Ces objets portent le nom d’objets de métadonnées sécurisables individuellement. Les autres objets de métadonnées héritent de la liste de contrôle d’accès de leur parent immédiat et portent le nom d’objets de métadonnées à accès contrôlé.

Résumé des droits

Le tableau suivant montre les droits que l’administrateur ou quiconque disposant du droit Gérer les autorisations peut définir sur une application du service BDC.

Tableau 1. Résumé des droits qui peuvent être définis sur une application BDC