À propos de la connexion de données, de l'authentification et du mappage des accès de substitution

L'utilisation des connexions de données dans les modèles de formulaire InfoPath activés pour le navigateur présente des problèmes potentiels d'authentification et de gestion qu'il convient de considérer. Ces problèmes peuvent être résolus à l'aide des fichiers UDC (Universal Data Connection) pour faire abstraction des informations de connexion de données du modèle de formulaire, à l'aide des services d'authentification unique d'Office pour gérer les problèmes d'authentification dans les architectures multiniveaux, et à l'aide du proxy de service Web disponible avec InfoPath Forms Services.

Connexions de données universelles

Windows SharePoint Services comprend la prise en charge d'une bibliothèque de connexions de données (DCL), qui peut contenir deux types de connexions de données : les fichiers de connexions de données Office et les fichiers de connexions de données universelles (UDC). Microsoft Office InfoPath 2007 utilise des connexions de données conformes au schéma des fichiers UDC et qui ont généralement une extension de fichier *.udcx ou *.xml. Ces fichiers UDC peuvent décrire différentes sources de données ; ils sont stockés sur le serveur et utilisés dans des modèles de formulaire standard et des modèles de formulaire activés pour le navigateur.

L'utilisation d'un fichier UDC situé dans une bibliothèque de connexions de données présente les avantages suivants :

• Les concepteurs de formulaires peuvent configurer des connexions de données de modèles de formulaire qui fonctionnent à la fois dans le client InfoPath et dans InfoPath Forms Services.

• Les concepteurs de formulaires peuvent publier un modèle de formulaire sur plusieurs serveurs et configurer différents paramètres de connexions de données pour chaque serveur sans modifier les informations de connexion de données du modèle de formulaire.

• Les concepteurs de formulaires peuvent publier un modèle de formulaire de sécurité de domaine pouvant accéder aux sources de données d'un autre domaine.

• Les administrateurs peuvent rediriger les connexions de données sans modifier les modèles de formulaire faisant référence au fichier UDC.

• Les administrateurs peuvent désigner les connexions autorisant l'accès inter-domaines.

• Les administrateurs peuvent publier des connexions de données sur un seul serveur, qui peuvent être partagées entre plusieurs serveurs.

Pour plus d'informations sur la manière de créer une bibliothèque de connexions de données, voir Procédure : créer et utiliser une bibliothèque de connexions de données. Les modèles de formulaire sont toujours conçus à partir des fichiers UDC d'une bibliothèque de connexions de données, mais vous pouvez configurer la connexion de façon à ce qu'elle utilise une version du fichier UDC gérée de manière centralisée. Ces fichiers sont chargés par un administrateur de serveur. Pour centraliser la gestion des fichiers UDC, allez sur la page Gestion des applications du site Administration centrale de SharePoint et cliquez sur le lien Gérer les fichiers de connexion de données de la section InfoPath Forms Services.

Lorsque le fichier UDC est chargé par l'administrateur, configurez les connexions de données de façon à ce qu'elles utilisent l'option Bibliothèque de connexions centralisée disponible en sélectionnant une connexion de données dans l'Assistant Connexion de données et en cliquant sur le bouton Options de connexion.

Sources de données prises en charge

Les fichiers UDC peuvent décrire plusieurs sources de données car, contrairement aux fichiers de connexions de données Office précédents, ils prennent en charge un éventail plus large de sources de données. Cependant, bien que la plupart des sources de données pouvant être configurées dans un modèle de formulaire InfoPath soient prises en charge, certains types de connexion de données, comme l'envoi de courrier électronique, ne peuvent pas être décrits dans un fichier UDC.

Les sources de données autorisées sont les suivantes :

• requête de base de données Microsoft SQL Server ;

• requête ou envoi de service Web ;

• requête de fichier XML (fichier XML situé sur un serveur distant) ;

• envoi de bibliothèque SharePoint ;

• requête de liste SharePoint ;

• envoi de serveur Web (HTTP Post).

Authentification des connexions de données

Tandis que les formulaires ouverts dans InfoPath peuvent communiquer directement avec les sources de données configurées pour le modèle de formulaire, les formulaires ouverts dans le navigateur communiquent directement avec le serveur qui exécute InfoPath Forms Services, qu'il s'agisse d'un serveur unique ou d'un client Web. Ceci nous amène à ce qui est communément appelé le problème de double saut. Le problème de double saut, ou plus précisément le problème de délégation sur plusieurs sauts, constitue un problème d'authentification où les informations d'identification requises pour accéder aux ressources d'un troisième ordinateur, ou troisième niveau, ne peuvent pas être utilisées pour accéder aux ressources du second niveau.

Par exemple, un formulaire du navigateur (le premier niveau) communique avec un serveur exécutant InfoPath Forms Services (le second niveau), lequel doit accéder aux ressources d'un serveur de base de données ou d'un partage réseau (le troisième niveau). Le jeton de sécurité principal utilisé entre le navigateur et le serveur exécutant InfoPath Forms Services ne peut pas être transféré au serveur de base de données en raison de restrictions de délégation inhérentes au système d'authentification NTLM utilisé par Microsoft Windows entre le navigateur et le serveur InfoPath Forms Services.

Ce problème se présente plus fréquemment avec les formulaires du navigateur, car les formulaires d'InfoPath peuvent s'authentifier directement avec la source de données, transférant le jeton d'authentification principal à ce serveur comme le fait le navigateur avec le serveur exécutant InfoPath Forms Services.

La fonction d'authentification unique (SSO, Single Sign-On) de Microsoft Office SharePoint Server 2007 constitue la meilleure méthode pour résoudre les problèmes de délégation dans les architectures multiniveaux, mais il existe d'autres options si l'authentification unique n'est pas disponible.

Solutions de délégation multiniveaux autres que l'authentification unique

Authentification de base/Digest : ce type d'authentification est généralement utilisé pour les formulaires HTML standard et peut être utile pour les formulaires InfoPath utilisés dans des scénarios extranet. L'utilisateur voit apparaître une boîte de dialogue l'invitant à entrer ses informations d'identification pour accéder aux ressources du serveur Web du troisième niveau, qui peuvent être utilisées comme relais pour accéder à un autre ordinateur Windows. Si le serveur est configuré pour une authentification de base, il envoie ces informations d'identification en texte clair, tandis qu'une authentification Digest les envoie à travers le réseau sous forme de hachage MD5 ou de synthèse de message.

Informations d'identification intégrées : vous pouvez intégrer les informations d'identification dans un fichier UDC (Universal Data Connection) mais cette alternative doit être choisie uniquement si la sécurité du nom d'utilisateur et du mot de passe permettant d'accéder aux ressources n'est pas menacée.

Utilisation d'un compte de service/anonyme : si le site SharePoint est configuré de sorte à autoriser l'accès anonyme, le serveur utilise un compte anonyme pour accéder aux ressources d'un troisième niveau.

Kerberos : Kerberos est un protocole d'authentification conçu pour prendre en charge la délégation dans les architectures multiniveaux. Avec Kerberos, un utilisateur s'authentifie avec son nom d'utilisateur et son mot de passe auprès d'un serveur de centre de distribution de clé (KDC, Key Distribution Center) et reçoit un ticket Kerberos. Ce dernier est chiffré et s'accompagne d'un vérificateur que seul le serveur peut déchiffrer. À chaque niveau de l'application, le ticket peut être vérifié indépendamment par le KDC sans les informations d'identification de l'utilisateur.

Délégation contrainte : Windows Server 2003 inclut deux extensions du service Kerberos appelées Délégation contrainte (DC) et Transition de protocole. Ces services permettent à Windows d'obtenir un ticket Kerberos pour le compte d'un utilisateur dans les scénarios extranet où le client ne peut pas utiliser Kerberos ou le port 88 (dédié à Kerberos) est bloqué. La plupart des serveurs Internet et des pare-feu d'entreprise bloquent le port 88 par défaut. Avec la délégation contrainte, tous les clients doivent être sous Windows XP ou une version ultérieure et tous les serveurs doivent être sous Windows Server 2003 ou une version ultérieure. Par ailleurs, elle doit être activée et configurée dans Active Directory.

Authentification basée sur les formulaires : les administrateurs SharePoint peuvent spécifier une authentification basée sur les formulaires comme mécanisme d'authentification auprès du serveur à utiliser par les utilisateurs. Ce type d'authentification suit le processus ci-dessous :

1. L'utilisateur émet une demande HTTP auprès du client Web (WFE).

2. Le WFE renvoie une réponse HTTP 302 (redirection) qui pointe vers un formulaire Web.

3. L'utilisateur entre ses informations d'identification dans le formulaire Web.

4. Les informations d'identification sont vérifiées par un fournisseur d'authentification de plug-in tiers et sont mappées aux informations reconnues par le WFE (comme un ID SharePoint).

Au terme du processus, l'utilisateur dispose d'un ID SharePoint valide. Toutefois, InfoPath Forms Services ne possède aucune information d'identification Windows valide pour établir une connexion, et le formulaire doit utiliser l'authentification unique ou une autre méthode pour obtenir les informations d'identification permettant de se connecter à la source de données.

Méthodes d'authentification recommandées : l'authentification unique et le proxy de service Web

Authentification unique : l'authentification unique d'Office se distingue des méthodes mentionnées plus haut en ce sens qu'elle fournit des informations d'identification de substitution permettant d'établir des connexions aux ressources des serveurs au-delà du second niveau. L'authentification unique est une base de données qui mappe les applications et les informations d'identification utilisateur à d'autres informations d'identification, et une API qui fait abstraction de la fonctionnalité d'authentification unique de façon à ce que tout fournisseur d'authentification unique incluant un fournisseur pour cette API puisse être utilisé. Les fournisseurs d'authentification unique suivants peuvent être utilisés par un administrateur de serveur de formulaires :

• Authentification unique d'entreprise

• Authentification unique Office Server

• Fournisseurs d'authentification unique tiers qui implémentent l'API d'authentification unique enfichable Office

L'authentification unique d'entreprise et l'authentification unique Office Server reposent sur la même base de code mais ont évolué dans deux directions différentes. L'authentification unique d'entreprise est intégrée à BizTalk Server 2006. L'authentification unique Office Server prend en charge un sous-ensemble de types d'authentification pris en charge par l'authentification unique d'entreprise, mais sa configuration est généralement plus facile et il est intégré à Office SharePoint Server 2007.

Pour plus d'informations sur la configuration de l'authentification unique Office Server, voir Vue d'ensemble de l'authentification unique dans le Kit de développement (SDK) Office Server.

Authentification du service Web multiniveau à l'aide du proxy : pour activer les demandes de service Web au sein d'une architecture multiniveau, le proxy InfoPath Forms Services est fourni pour transférer les messages SOAP du service Web à partir du formulaire du navigateur.

L'option permettant d'activer le proxy se trouve sur la page Gestion des applications du site Administration centrale de SharePoint. Cliquez sur le lien Gérer le proxy du service Web dans la section InfoPath Forms Services pour activer le proxy pour les formulaires déployés par l'administrateur et/ou l'utilisateur.

Mappage des accès de substitution et connexions de données SharePoint

Le mappage des accès de substitution de SharePoint est un mécanisme qui permet aux administrateurs de batteries de serveurs d'identifier les différentes manières qu'ont les utilisateurs pour accéder aux sites du portail et de garantir que les URL s'affichent de façon appropriée par rapport au mode d'accès des utilisateurs aux sites SharePoint. Par exemple, un utilisateur d'un intranet d'entreprise accède au site des avantages de sa société à l'aide de l'URL http://benefits, alors qu'un employé de la société accède au même site depuis son domicile à partir de l'extranet via l'URL https://benefits.mycompany.com.

Le mappage des accès de substitution n'affecte généralement pas la manière dont les connexions de données sont gérées par InfoPath Forms Services. Cependant, si les utilisateurs accèdent aux formulaires depuis des sites intranet et extranet, le modèle d'authentification des connexions de données doit être configuré et testé à partir des deux emplacements pour en garantir le bon fonctionnement. Les connexions à un serveur via une URL complète, au lieu d'un nom de serveur local, dépendent du mappage des accès de substitution pour garantir la connectivité.

Pour afficher les paramètres de mappage des accès de substitution dans l'Administration centrale de SharePoint, allez sur la page Opérations et cliquez sur le lien Mappage des accès de substitution dans la section Configuration globale. Pour plus d'informations sur le mappage des accès de substitution, recherchez « mappage des accès de substitution » sur le site de Microsoft Office SharePoint Server TechCenter.

Voir aussi

Référence

Planifier les mappages des accès de substitution

Autres ressources

Procédure : créer et utiliser une bibliothèque de connexions de données