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.
Notes
Pour déterminer le modèle d’authentification à utiliser pour chaque mode, voir Modèles d’authentification pour les modes d’authentification .
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.
.gif "Note Attention") 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.
Mode d'authentification |
Application |
Scénarios d’utilisation |
|---|---|---|
PassThrough |
Bases de données et services Web |
Utilisez ce mode dans un environnement de test avec une configuration de serveur unique (serveur de bases de données et serveur exécutant SharePoint Server sur le même ordinateur) ou si la délégation Kerberos est activée dans votre domaine. Vous pouvez également l’utiliser si le serveur de destination ou le service Web a recours à l’authentification anonyme ou à des connexions SSL. |
RevertToSelf |
Bases de données et services Web |
Utilisez ce mode si vous devez rétablir l’identité et procéder à l’authentification en tant que compte sous-jacent configuré pour le pool d’applications IIS. |
WindowsCredentials |
Bases de données et services Web |
Utilisez ce mode si le serveur de bases de données ou le service Web utilise l’authentification Windows. Ce mode nécessite la configuration du Service Banque d’informations sécurisé. |
RdbCredentials |
Systèmes de base de données uniquement |
Utilisez ce mode si votre serveur de bases de données utilise des informations d’identification de base de données, par exemple, si votre serveur exécutant SQL Server utilise l’authentification SQL Server au lieu de l’authentification Windows. Ce mode nécessite la configuration du Service Banque d’informations sécurisé. |
Credentials |
Systèmes de service Web uniquement |
Utilisez ce mode si le service Web utilise des informations d’identification autres que Windows. Ce mode nécessite la configuration du Service Banque d’informations sécurisé. |
DigestCredentials |
Systèmes de service Web WCF uniquement |
Utilisez ce mode si le service Web WCF utilise des informations d’identification autres que les informations d’identification Windows pour l’authentification Digest. Ce mode nécessite la configuration du Service Banque d’informations sécurisé. |
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.
Modèle / Mode |
PassThrough |
RevertToSelf |
Credentials, DigestCredentials, RdbCredentials, WindowsCredentials (Application de Banque d’informations sécurisée spécifique) |
Credentials, DigestCredentials, RdbCredentials, WindowsCredentials (Groupe d’applications de Banque d’informations sécurisée) |
|---|---|---|---|---|
Sous-système approuvé |
Oui |
Oui |
||
Emprunt d'identité et délégation |
Oui |
Oui |
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
Dans la propriété SecondarySsoApplicationId de LobSystemInstance, spécifiez l’application de Banque d’informations sécurisée qui contient les informations d’identification.
Définissez un UsernameCredentialFilter et un PasswordCredentialFilter, puis associez chacun d'eux à un paramètre d'entrée.