Vous êtes redirigé vers une page d’ouverture de session ou une page d’erreur, ou vous êtes invité à fournir des informations d’authentification lorsque vous cliquez sur un lien hypertexte vers un site web d’authentification unique dans un document Office

Symptômes

Lorsque vous cliquez sur un lien hypertexte dans un document Microsoft Office, vous pouvez rencontrer le comportement suivant avant de pouvoir ouvrir la page que vous avez demandée :

  • Vous êtes redirigé vers une page d’ouverture de session ou une page d’erreur
  • Vous êtes invité à fournir des informations d’authentification.

En règle générale, ce comportement se produit lorsque les conditions suivantes sont remplies :

  • Vous ouvrez le document Office en mode édition en dehors du navigateur Web.
  • Le site Web dans le lien hypertexte utilise un système d’authentification Sign-On unique (SSO) qui s’appuie sur des cookies de session HTTP pour l’identification du client. Même si vous avez déjà fourni des informations d’identification utilisateur, vous êtes invité à fournir à nouveau les informations d’identification de l’utilisateur.

Cause

Office vous permet de modifier et de créer des documents sur un site Web si le serveur prend en charge la création et la collaboration web. Tout d’abord, Office tente de communiquer avec le serveur Web. Office tente ensuite de lier directement à la ressource à l’aide de la bibliothèque de liens hypertexte Microsoft (Hlink.dll) et de l’API URLMON.

Quand Office envoie la demande de page Web, vous pouvez être redirigé vers la page d’ouverture de session du site Web pour le système d’authentification unique. Ce comportement se produit parce que la session Office est indépendante de la session de navigateur Web dans laquelle vous avez peut-être déjà fourni des informations d’identification utilisateur.

Étant donné que les sessions sont indépendantes, les cookies de session ne sont pas partagés. Si le système d’authentification unique s’appuie exclusivement sur les informations de cookie de session, le système d’authentification unique peut ne pas fonctionner, car le même utilisateur passe de plusieurs sessions. Ce comportement est une limitation de conception fondamentale d’un système d’authentification unique lorsque le système d’authentification unique n’est pas conçu pour prendre en charge l’authentification unique sur plusieurs navigateurs ou applications web sur le bureau client. Étant donné qu’Office est une application entièrement compatible avec le web, le problème peut sembler propre aux applications Office s’il s’agit des seuls clients web installés par le client. Toutefois, la cause racine de ce problème n’est pas limitée à Microsoft Office, et ce problème peut se produire lorsque vous utilisez des logiciels tiers.

Solution de contournement

Le problème est une limitation du système d’authentification unique utilisé par le serveur Web. Toutefois, vous pouvez réduire les effets actuels de votre site Web protégé par l’authentification unique à l’aide de l’une des méthodes suivantes.

Si ce problème se produit lorsque des liens hypertexte sur une page Web ouvrent un fichier Office et que la page Web est hébergée dans Internet Explorer, vous pouvez éviter ce problème en marquant explicitement le contenu en tant que téléchargement en lecture seule plutôt qu’en tant que navigation inline.

Pour ce faire, ajoutez un en-tête HTTP personnalisé à la réponse GET pour le contenu du fichier Office. Ajoutez l’en-tête « Content-Disposition : Pièce jointe ». Lorsqu’une réponse GET contient cet en-tête, Internet Explorer invite l’utilisateur à ouvrir ou enregistrer le téléchargement. Si l’utilisateur choisit d’ouvrir le téléchargement, le fichier s’ouvre à partir d’Internet Explorer cache de fichiers temporaires en lecture seule. L’utilisateur peut choisir de modifier et d’enregistrer le fichier localement. Toutefois, l’utilisateur ne sera pas en mesure d’enregistrer le fichier sur le serveur ou de collaborer avec les services Web pour le site Web. Par conséquent, cette solution ne fonctionne que si vous envisagez de rendre le fichier en lecture seule.

Vous pouvez définir l’en-tête « Content-Disposition » à l’aide du code dans Microsoft Active Server Pages (ASP), dans Microsoft ASP.NET ou dans ISAPI lorsque vous travaillez avec du contenu généré dynamiquement. Si le contenu est statique, vous pouvez configurer l’en-tête d’un fichier ou dossier donné à l’aide du Gestionnaire iis et de la métabase IIS. Pour plus d’informations sur l’en-tête HTTP Content-Disposition, consultez La boîte de dialogue Comment déclencher un téléchargement de fichier pour un type MIME connu.

Si ce problème se produit lorsque vous cliquez sur des liens hypertexte dans des documents Office qui ouvrent directement du contenu web HTML ou qui sont redirigés vers du contenu HTML, les utilisateurs clients peuvent éviter le problème en activant une clé de Registre pour envoyer la navigation du lien hypertexte au navigateur au lieu de lier directement le lien hypertexte à partir d’Office. Pour plus d’informations, voir Message d’erreur lorsque vous cliquez sur un lien hypertexte dans Office : « Impossible de localiser le serveur Internet ou le serveur proxy ».

Remarque

Quelle que soit la version d’Office que vous avez installée, ajoutez la clé de Registre à l’emplacement exact spécifié dans Message d’erreur lorsque vous cliquez sur le lien hypertexte dans Office : « Impossible de localiser le serveur Internet ou le serveur proxy ».

Lorsque vous utilisez ce paramètre de Registre, le composant HLINK utilisé par Office ouvre le lien hypertexte dans le navigateur Web par défaut. Ce paramètre de Registre affecte tous les clients HLINK, pas seulement Office. Par conséquent, utilisez cette clé de Registre avec soin.

Informations supplémentaires

Pour résoudre entièrement ce problème, nous encourageons les fournisseurs d’authentification unique à développer un système qui pourrait permettre la création web et un client qui utilise plusieurs sessions. Cette configuration ajoute de la complexité au système d’authentification unique. Toutefois, cette configuration offre également aux clients les options les plus pratiques. Microsoft travaille actuellement avec des fournisseurs d’authentification unique clés pour une solution à long terme.

En outre, Microsoft étudie la façon dont les utilisateurs finaux utilisent Office pour mieux prédire et gérer les scénarios suivants :

  • L’utilisateur a l’intention d’ouvrir un lien hypertexte en mode lecture seule. Dans ce scénario, le lien hypertexte est ouvert en mode de navigation.
  • L’utilisateur souhaite modifier le contenu. Dans ce scénario, une nouvelle session est requise pour la création et la collaboration.

Ces modifications de configuration peuvent réduire l’effet du problème décrit dans la section « Symptômes ». Ces modifications peuvent également ajouter de la flexibilité pour l’utilisateur lorsque celui-ci visite un site d’authentification unique qui ne prend pas en charge les configurations qui incluent des clients à plusieurs sessions.

Si vous êtes concepteur ou développeur d’authentification unique, vous pouvez ajouter la prise en charge des clients à plusieurs sessions. Par exemple, vous pouvez utiliser les méthodes suivantes :

  • Utilisez les informations sur les cookies persistants et les informations sur les cookies de session pour identifier quand un client a croisé des sessions entre des applications sur le bureau. Ensuite, fournissez des réponses web pour transférer le client dans une session unique ou pour authentifier la nouvelle session.

  • Utilisez un composant côté client pour créer un système d’authentification intégré. Utilisez ce système d’authentification intégré pour authentifier tous les processus démarrés sous le même jeton d’authentification utilisateur.

  • Utilisez des certificats ou une autre méthode d’identification permanente à sécurité renforcée pour authentifier le client.

  • Pour une requête HTTP qui peut être une requête cliente à plusieurs sessions, émettez une réponse de redirection côté client au lieu d’une réponse de redirection côté serveur. Par exemple, envoyez un script HTTP ou une balise META REFRESH au lieu d’une réponse HTTP 302. Cette modification force le client à revenir au navigateur web par défaut de l’utilisateur. Par conséquent, la session de navigateur par défaut peut gérer l’appel et conserver l’appel dans une seule session en lecture seule.

    Cette méthode n’autorise pas la création. Toutefois, cette méthode indique clairement que le système d’authentification unique ne gère pas les clients à plusieurs sessions et souhaite que le client reste uniquement dans la session de navigateur par défaut.

L’approche exacte de ce changement de configuration dépend de vos objectifs de conception et du niveau d’intégration que vous souhaitez avoir avec le bureau client.