Authentification du service Business Data Connectivity

Dernière modification : mercredi 28 juillet 2010

S’applique à : SharePoint Server 2010

Dans cet article
Modes d'authentification
Modèles d’authentification pour les modes d’authentification
Authentification de niveau application

Le Service BDC (Business Data Connectivity) prend en charge deux modèles d’authentification :

• Sous-système autorisé

• Emprunt d'identité et délégation

Dans le modèle Sous-système autorisé, le niveau intermédiaire (généralement, le serveur Web) s’authentifie auprès du serveur principal en tant qu’identité fixe. Choisissez le modèle Sous-système autorisé pour les raisons suivantes :

• Le groupe propriétaire qui gère le serveur principal donne accès à un compte qu'il gère.

• Il permet le regroupement des connexions.

• Il réduit les coûts de licences sur le serveur principal.

• Il est moins complexe.

Dans le modèle Emprunt d’identité et délégation, le client délègue l’authentification au niveau intermédiaire. Le niveau intermédiaire emprunte alors l’identité du client et s’authentifie auprès du serveur principal au nom du client. Vous utiliserez ce modèle pour les raisons suivantes :

• prendre en charge l’exigence de l’autorisation par utilisateur sur le serveur principal.

• activer l’audit sur le serveur principal ;

Modes d'authentification

Les modes d’authentification ci-après sont disponibles lorsque BDC est utilisé à des fins de connexion à une base de données ou un service Web.

Authentification Pass-Through (systèmes de base de données et de service Web)

L’authentification directe (ou Pass-Through) désigne la capacité du système d’exploitation à transmettre les informations d’authentification d’un client au serveur principal. BDC la prend en charge pour les connexions de base de données et de service Web. Lors de l’utilisation de ce mode d’authentification, vous vous authentifiez avec l’identité de l’utilisateur connecté.

Lorsque BDC fait l’objet d’un accès à partir d’une page Web, il exécute le processus de traitement w3wp.exe d’Internet Information Services (IIS) sur le serveur Web frontal. L’identité de ce processus est le compte du pool d’applications IIS mais le thread utilisé pour répondre à la demande emprunte l’identité de l’utilisateur connecté. Pour éviter de perdre l’identité de l’utilisateur connecté lorsque BDC s’authentifie auprès du serveur principal, vous devez activer la délégation Kerberos entre le serveur IIS et l’autre ordinateur. La délégation Kerberos permet à un serveur de réception d’envoyer la demande d’authentification à l’emplacement adéquat.

Lorsque BDC est utilisé à des fins d’analyse, il exécute le démon de filtre mssdmn.exe. Pour accéder à la source de contenu principale, les threads du processus du démon de filtre empruntent l’identité du compte d’accès au contenu associé à cette source de contenu principale.

L’un des inconvénients associés à l’utilisation de l’authentification directe réside dans le fait que le système d’exploitation n’expose que le nom d’utilisateur et le mot de passe. Si une entreprise a recours à une authentification basée sur deux facteurs (authentification dans laquelle les utilisateurs doivent fournir des informations privées ou spécifiques en plus de leur nom d’utilisateur et mot de passe), l’authentification directe ne fonctionne pas.

Malgré cet inconvénient, la simplicité d’utilisation de l’authentification directe fait de celle-ci une solution idéale pour les environnements de test ou si le serveur de destination utilise l’authentification anonyme.

Authentification RevertToSelf (systèmes de base de données et de service Web)

Si un utilisateur ouvre une session avec l’authentification Windows, IIS emprunte l’identité de ce compte spécifique. Alors qu’IIS s’exécute sous l’identité du pool d’applications, il emprunte l’identité de l’utilisateur connecté, et la demande s’effectue sous l’identité de l’utilisateur avant d’être transférée.

L’authentification RevertToSelf vous permet de rétablir cette identité et de procéder à l’authentification en tant que compte sous-jacent configuré pour le pool d’applications IIS.

Attention
Si du code personnalisé utilise la méthode RevertToSelf pour l’authentification, il peut accorder aux utilisateurs des privilèges système sur les serveurs principaux en accordant des privilèges à l’identité du pool d’applications. Vous ne devez donc pas exécuter du code personnalisé sur un système de production tant que celui-ci n’a pas fait l’objet de tests approfondis.

WindowsCredentials (systèmes de base de données et de service Web)

Microsoft SharePoint Server 2010 procède à l’authentification à l’aide des informations d’identification Windows obtenues à partir de son Service Banque d’informations sécurisé par défaut.

RdbCredentials (systèmes de base de données uniquement)

En mode RdbCredentials, SharePoint Server 2010 procède à l’authentification à l’aide des informations d’identification de la base de données contenues dans son Service Banque d’informations sécurisé par défaut. SharePoint Server ajoute ces informations à la chaîne de connexion, puis les transmet au serveur de bases de données.

Credentials (systèmes de service Web uniquement)

SharePoint Server 2010 authentifie les systèmes de service Web à l’aide d’informations d’identification autres que celles de l’authentification Windows contenues dans son Service Banque d’informations sécurisé par défaut. Ces informations sont utilisées pour l’authentification de base ou Digest, selon la configuration du serveur des services Web. Étant donné que l’authentification de base et l’authentification Digest ne protègent pas suffisamment les informations d’identification, vous devez utiliser SSL (Secure Sockets Layer ) ou IPSec (Internet Protocol Security), ou les deux, pour faciliter la sécurisation des communications entre le serveur des services Web et celui exécutant BDC.

DigestCredentials (systèmes de service Web WCF uniquement)

Avec le mode d’authentification DigestCredentials, SharePoint Server 2010 utilise le Service Banque d’informations sécurisé par défaut pour mapper les informations d’identification de l’utilisateur à des informations d’identification autres que celles utilisées pour l’authentification Windows. Les informations d’identification mappées sont utilisées pour l’authentification Digest. Celle-ci ne protégeant pas suffisamment les informations d’identification, vous devez utiliser le protocole SSL (Secure Sockets Layer ), la sécurité IPSec (Internet Protocol Security) ou les deux pour faciliter la sécurisation des communications entre le serveur des services Web WCF et celui exécutant BDC.

Synthèse

Le tableau 1 indique dans quel cas vous devez utiliser chaque mode d’authentification. Il contient également des liens vers des exemples disponibles dans le SDK SharePoint 2010.

Modèles d’authentification pour les modes d’authentification

Le tableau ci-après montre le modèle d’authentification suivi par chaque mode d’authentification.

Authentification de niveau application

BDC prend également en charge une authentification de niveau application secondaire, qui est utilisée en plus de l’authentification principale configurée pour le système. Cela s’avère particulièrement utile lorsqu’une application principale a besoin que des informations d’identification de sécurité soient passées dans les appels de méthode pour l’autorisation des utilisateurs.

Vous pouvez activer l’authentification au niveau de l’application en définissant des filtres dans le modèles BDC, à savoir les filtres de nom d’utilisateur, mot de passe, SSOTicket et UserContext. Pour plus d’informations sur ces filtres, voir Types de filtres pris en charge par le service Business Data Connectivity.

La procédure suivante illustre comment activer l’authentification au niveau de l’application en ajoutant les filtres de nom d’utilisateur et de mot de passe au modèle BDC.

Pour activer l’authentification de niveau application

1. Dans la propriété SecondarySsoApplicationId de LobSystemInstance, spécifiez l’application de Banque d’informations sécurisée qui contient les informations d’identification.

2. Définissez un UsernameCredentialFilter et un PasswordCredentialFilter, puis associez chacun d'eux à un paramètre d'entrée.