Modes d'authentification disponibles
Les modes d'authentification ci-après sont disponibles lorsque le catalogue de données métiers est utilisé à des fins de connexion à un service Web.
Authentification directe
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 les connexions de service Web. Lors de l'utilisation de ce mode d'authentification, vous vous authentifiez avec l'identité de l'utilisateur final.
Lorsque vous accédez au catalogue de données métiers à partir d'une page Web, ce dernier 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 vous utilisez le catalogue de données métiers à 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 (si 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.
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 service Web ou le serveur de destination utilise l'authentification anonyme ou des connexions SSL.
Authentification RevertToSelf
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 octroyant des privilèges à l'identité du pool d'applications. Veillez à tester soigneusement tout code personnalisé avant de l'exécuter sur un système de production.
Authentification WindowsCredentials
Microsoft Office SharePoint Server 2007 effectue l'authentification en utilisant les informations d'identification Windows à partir de son service d'authentification unique par défaut (SSO). Utilisez ce mode si votre service Web utilise l'authentification Windows. Vous devez configurer SSO avant d'utiliser ce mode. Lorsque vous utilisez les informations d'identification Windows, le catalogue de données métiers essaie de fractionner le champ nom d'utilisateur retourné à partir de SSO en domaine\utilisateur, puis utilise le trinôme domaine, nom d'utilisateur et mot de passe pour s'authentifier.
Authentification à l'aide des informations d'identification
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 (SSO) 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 et/ou IPSec pour sécuriser les communications entre le serveur des services Web et celui exécutant le catalogue de données métiers.
Utilisez ce mode si votre service Web utilise des informations d'identification autres que les informations d'identification Windows. Vous devez configurer SSO avant d'utiliser ce mode. Lorsque vous utilisez les informations d'identification, le catalogue de données métiers ne tente pas de fractionner le champ nom d'utilisateur retourné à partir de SSO en domaine\utilisateur comme dans le mode WindowsCredentials, mais utilise directement le nom d'utilisateur et le mot de passe à partir de SSO pour s'authentifier.
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 lorsqu'une application principale a besoin que des informations d'identification de sécurité soient passées dans les appels de méthode, par exemple, pour l'autorisation des utilisateurs ou pour une méthode Web qui recherche des informations d'identification dans les en-têtes HTTP ou SOAP. 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.
Si votre application principale requiert la transmission d'informations d'identification de sécurité dans les appels de méthode, définissez un filtre Username et un filtre Password, puis associez chacun d'eux à un paramètre d'entrée.
Si votre application principale requiert la transmission d'informations d'identification de sécurité sous la forme d'en-têtes HTTP, définissez la propriété HttpUsername et la propriété HttpPassword sur la méthode.
Si votre application principale requiert la transmission d'informations d'identification de sécurité sous la forme d'en-têtes SOAP, définissez la propriété SOAPUsername et la propriété SOAPPassword sur la méthode.
Filtre UserContext
Le filtre UserContextlimite les instances renvoyées par une méthode au contexte actif de l'utilisateur. Ce filtre indique au catalogue de données métiers d'ajouter le domaine/nom d'utilisateur de l'utilisateur Microsoft Windows actif à l'appel de la méthode.
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, un utilisateur peut voir les données d'un autre. Pour éviter ce problème, utilisez le filtre UserContext pour transférer le nom d'utilisateur à l'appel de méthode.
Pour plus d'informations, voir FilterDescriptor.
Important
Si vous obtenez une erreur d'importation de définition d'application indiquant que le catalogue de données métiers ne peut pas se connecter à WSDL, notez que WSDL n'est peut-être pas public. Dans ce cas, vous devez configurer l'authentification en utilisant l'un des modes abordés dans cette rubrique ou copier manuellement WSDL sur le système local et pointer WSDLFetchURL sur l'URL de fichier.
Voir aussi
Autres ressources
Catalogue de données métiers : modèle de sécurité
Prise en charge des en-têtes HTTP et SOAP personnalisés