Authentification du catalogue de données métiers
Le catalogue de données métiers 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. Vous choisirez généralement ce modèle pour les raisons suivantes :
Il permet le regroupement des connexions de la base de données.
Il réduit les coûts de licences sur le serveur principal.
Il est moins complexe.
Le groupe propriétaire qui gère le serveur principal donne accès à un compte qu'il gère.
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 choisirez ce modèle pour les raisons suivantes :
activer l'audit sur le serveur principal ;
s'il existe une autorisation par utilisateur sur le serveur principal.
Modes d'authentification
Les modes d'authentification ci-après sont disponibles lorsque le catalogue de données métiers est utilisé à des fins de connexion à une base de données ou un service Web.
PassThrough (systèmes de base de données et de service Web)
L'authentification directe fait référence à la possibilité du système d'exploitation de transmettre les informations d'authentification d'un client au serveur principal. Le catalogue de données métiers la prend en charge pour les connexions de base de données et de service Web. Lors de l'utilisation ce mode d'authentification, vous vous authentifiez avec l'identité de l'utilisateur final.
Lorsque le catalogue de données métiers fait l'objet d'un accès à partir d'une page Web, il exécute le processus de traitement w3wp.exe de Microsoft Internet Information Services (IIS) . L'identité de ce processus est le compte du pool d'applications IIS prenant l'identité de l'utilisateur connecté. Pour éviter de perdre l'identité de l'utilisateur connecté lorsque le catalogue de données métiers s'authentifie auprès du serveur principal, vous devez activer la délégation Kerberos entre le serveur exécutant 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 le catalogue de données métiers 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 spécifiques en plus de leur nom d'utilisateur et mot de passe), vous ne pouvez donc pas l'utiliser.
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. Vous pouvez également y avoir recours si le serveur de destination utilise l'authentification anonyme ou des connexions SSL.
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.
Avertissement
Si du code personnalisé utilise 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 jamais 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 Office SharePoint Server 2007 procède à l'authentification à l'aide des informations d'identification Microsoft Windows contenues dans son service d'authentification unique par défaut.
RdbCredentials (systèmes de base de données uniquement)
En mode RdbCredentials, Office SharePoint Server 2007 procède à l'authentification à l'aide des informations d'identification de la base de données contenues dans son service d'authentification unique par défaut. Office SharePoint Server 2007 ajoute ces informations à la chaîne de connexion, puis les transmet au serveur de base de données.
Credentials (systèmes de service Web uniquement)
Office SharePoint Server 2007 authentifie les systèmes de service Web à l'aide d'informations d'identification autres que celles de l'authentification Windows contenues dans son service d'authentification unique 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 ou IPSec, ou les deux, pour sécuriser les communications entre le serveur des services Web et celui exécutant la catalogue de données métiers.
Synthèse
Le tableau ci-après indique dans quel cas vous devez utiliser chaque mode d'authentification. Il contient également des liens vers des exemples disponibles dans le Kit de développement logiciel (SDK).
| Mode d'authentification | Application | Scénarios | Exemple |
|---|---|---|---|
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 SharePoint Server sur le même serveur) 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. |
Étape 1 : se connecter à la base de données AdventureWorks2000 Exemple SQL Server 2005 AdventureWorksDW |
RevertToSelf |
Bases de données et services Web |
||
WindowsCredentials |
Bases de données et services Web |
Utilisez ce mode si le serveur de base de données ou le service Web utilise l'authentification Windows. Ce mode nécessite la configuration de l'authentification unique. |
|
RdbCredentials |
Systèmes de base de données uniquement |
Utilisez ce mode si votre serveur de base de données utilise des informations d'identification de base de données (lorsque le serveur SQL Server utilise l'authentification SQL Server au lieu de l'authentification Windows, par exemple). Ce mode nécessite la configuration de l'authentification unique. |
|
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 de l'authentification unique. |
Modes d'authentification et modèles d'authentification
Le tableau ci-après montre quel modèle d'authentification suive chaque mode d'authentification.
| Modèle \ Mode | PassThrough | RevertToSelf | Credentials, RdbCredentials, WindowsCredentials (Application d'authentification unique spécifique) | Credentials, RdbCredentials, WindowsCredentials (Groupe d'applications d'authentification unique) |
|---|---|---|---|---|
Sous-système approuvé |
X |
X |
||
Emprunt d'identité et délégation |
X |
X |
Authentification de niveau application
Le catalogue de données métiers prend également en charge une authentification de niveau application secondaire. Cette authentification est utilisée en plus de l'authentification principale configurée pour le système, ce qui s'avère particulièrement utile lorsque 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, par exemple. Pour activer l'authentification de niveau application, effectuez les opérations décrites ci-après.
Dans la propriété SecondarySsoApplicationId de LobSystemInstance, spécifiez l'application d'authentification unique qui contient les informations d'identification.
Définissez un UsernameCredentialFilter et un PasswordCredentialFilter, puis associez chacun d'eux à un paramètre d'entrée.
Voir aussi
Autres ressources
Autorisation du catalogue de données métiers
Exemples liés au catalogue de données métiers