Authentification passport dans WinHTTP
Les services HTTP Microsoft Windows (WinHTTP) prennent entièrement en charge l’utilisation côté client du protocole d’authentification Microsoft Passport. Cette rubrique fournit une vue d’ensemble des transactions impliquées dans l’authentification Passport et de la façon de les gérer.
Notes
Dans WinHTTP 5.1, l’authentification Passport est désactivée par défaut.
Passport 1.4
Passport est un composant principal des services de blocs de construction Microsoft .NET. Il permet aux entreprises de développer et d’offrir des services Web distribués sur un large éventail d’applications et permet à ses membres d’utiliser un nom de connexion et un mot de passe sur tous les sites Web participants.
WinHTTP fournit une prise en charge de la plateforme pour Microsoft Passport 1.4 en implémentant le protocole côté client pour l’authentification Passport 1.4. Il libère les applications des détails de l’interaction avec l’infrastructure Passport et les noms d’utilisateur et mots de passe stockés dans Windows XP. Cette abstraction ne diffère pas de l’utilisation de Passport du point de vue d’un développeur de l’utilisation de schémas d’authentification traditionnels tels que Basic ou Digest.
Windows XP : La clé de Registre HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Passport\NumRegistrationRuns identifie le nombre de fois où l’Assistant Authentification de passeport s’affiche lorsque l’authentification PassPort est requise. Si la valeur de cette clé est définie sur un nombre supérieur à 5, l’Assistant n’est pas affiché.
Les sections suivantes décrivent les transactions impliquées dans l’authentification Passport du point de vue d’une application cliente. Pour le développement de Passport côté serveur, consultez La vue d’ensemble de la documentation du Kit de développement logiciel (SDK) Passport.
Demande initiale
Lorsqu’un client demande une ressource sur un serveur qui nécessite l’authentification Passport, le serveur vérifie la présence de tickets dans la demande. Si un ticket valide est envoyé avec la demande, le serveur répond avec la ressource demandée. Si le ticket n’existe pas sur le client, le serveur répond avec un code 302 status. La réponse inclut l’en-tête du défi, « WWW-Authenticate : Passport1.4 ». Les clients qui n’utilisent pas Passport peuvent suivre la redirection vers le serveur de connexion Passport. Les clients plus avancés contactent généralement le nexus Passport pour déterminer l’emplacement du serveur de connexion Passport.
Notes
Le Nexus Passport est au centre du réseau Microsoft Passport, qui facilite la synchronisation des sites des participants Passport pour s’assurer que chaque site dispose des dernières informations sur la configuration du réseau et d’autres problèmes. Chaque composant Passport (Passport Manager, serveurs de connexion, serveurs de mise à jour, etc.) communique régulièrement avec nexus pour récupérer les informations dont il a besoin pour localiser et communiquer correctement avec les autres composants du réseau Passport. Ces informations sont récupérées sous la forme d’un document XML appelé document de configuration de composant ou CCD.
L’image suivante montre la demande initiale adressée à un affilié Passport.
Serveur de connexion Passport
Un serveur de connexion Passport gère toutes les demandes de tickets pour n’importe quelle ressource dans une autorité de domaine Passport. Pour qu’une demande puisse être authentifiée à l’aide de Passport, l’application cliente doit contacter le serveur de connexion pour obtenir les tickets appropriés.
Lorsqu’un client demande des tickets à un serveur de connexion Passport, le serveur de connexion répond généralement avec un code 401 status pour indiquer que les informations d’identification de l’utilisateur doivent être fournies. Lorsque ces informations d’identification sont fournies, le serveur de connexion répond avec les tickets nécessaires pour accéder à la ressource spécifiée sur le serveur qui contient la ressource demandée à l’origine. Le serveur de connexion peut également rediriger le client vers un autre serveur qui peut fournir la ressource demandée.
Demande authentifiée
Lorsque le client a les tickets correspondant à un serveur donné, ces tickets sont inclus avec toutes les demandes adressées à ce serveur. Si les tickets n’ont pas été modifiés depuis qu’ils ont été récupérés à partir du serveur de connexion Passport et que les tickets sont valides pour le serveur de ressources, le serveur de ressources envoie une réponse qui inclut à la fois la ressource demandée et les cookies qui indiquent que l’utilisateur est authentifié pour les demandes futures.
Les cookies supplémentaires dans la réponse sont destinés à accélérer le processus d’authentification. Les demandes supplémentaires dans la même session pour les ressources sur les serveurs de la même autorité de domaine Passport incluent toutes ces cookies supplémentaires. Les informations d’identification n’ont pas besoin d’être envoyées à nouveau au serveur de connexion tant que les cookies n’ont pas expiré.
Utilisation de Passport dans WinHTTP
L’authentification Passport dans WinHTTP est très similaire à d’autres schémas d’authentification. Pour obtenir une vue d’ensemble de l’authentification dans WinHTTP, consultez Authentification dans WinHTTP .
Dans WinHTTP 5.1, l’authentification Passport est désactivée par défaut et doit être explicitement activée avec WinHttpSetOption avant l’utilisation.
WinHTTP gère la plupart des détails de la transaction en interne pour l’authentification Passport. Lors de la demande initiale, le serveur répond avec un code 302 status lorsque l’authentification est nécessaire. Le code 302 status indique en fait une redirection et fait partie du protocole Passport pour la compatibilité descendante. WinHTTP masque le code 302 status et contacte le nexus Passport, puis le serveur de connexion. L’application WinHTTP est informée du code 401 status envoyé par le serveur de connexion pour demander les informations d’identification de l’utilisateur. Toutefois, pour l’application, il semble que la status 401 provient du serveur à partir duquel la ressource a été demandée. De cette façon, l’application WinHTTP ignore les interactions avec d’autres serveurs et peut gérer l’authentification Passport avec le même code que celui qui gère d’autres schémas d’authentification.
En règle générale, une application WinHTTP répond à un code 401 status en fournissant des informations d’identification d’authentification. Lorsque les informations d’identification sont fournies avec WinHttpSetCredentials ou SetCredentials pour l’authentification par passeport, les informations d’identification sont en fait envoyées au serveur de connexion, et non au serveur indiqué dans la demande.
Toutefois, lorsqu’elle répond à un code 407 status, une application WinHTTP doit utiliser WinHttpSetOption pour fournir des informations d’identification de proxy, plutôt que WinHttpSetCredentials. Étant donné que WinHttpSetOption est un moyen moins sécurisé de fournir des informations d’identification, il doit normalement être évité.
Une fois récupérés, les tickets sont gérés en interne et sont automatiquement envoyés aux serveurs applicables dans les demandes futures.
Notes
WinHTTP vous permet de désactiver la redirection automatique en appelant la fonction WinHttpSetOption pour l’indicateur WINHTTP_OPTION_DISABLE_FEATURE et en spécifiant une valeur de WINHTTP_DISABLE_REDIRECTS. La désactivation de la redirection n’interfère pas avec la redirection que WinHTTP gère en interne pour les transactions Passport.
WinHTTP peut effectuer l’authentification Passport même si une application désactive la redirection automatique. Toutefois, une fois l’authentification Passport terminée, une redirection implicite doit se produire à partir de l’URL du serveur de connexion Passport vers l’URL d’origine. Cette redirection n’est pas déclenchée par une réponse HTTP 302, mais est implicite dans le protocole Passport.
WinHTTP gère spécialement cette redirection implicite. Si une application a désactivé la redirection automatique, WinHTTP exige que l’application donne à WinHTTP « l’autorisation » de rediriger automatiquement dans ce cas particulier.
Pour que WinHTTP redirige vers l’URL d’origine après l’authentification, l’application doit inscrire une fonction de rappel à l’aide de WinHttpSetStatusCallback. WinHTTP peut ensuite notifier l’application avec un rappel WINHTTP_CALLBACK_STATUS_REDIRECT, ce qui permet à l’application d’annuler la redirection. Une application n’a pas besoin de fournir de fonctionnalité dans la fonction de rappel ; l’inscription du rappel est suffisante pour permettre à WinHTTP de suivre cette redirection de cas spécial.
Le message ERROR_WINHTTP_LOGIN_FAILURE est généré si une fonction de rappel n’est pas définie par l’application.
Passport Cobranding
Contrairement aux schémas d’authentification traditionnels pris en charge par WinHTTP, Passport peut être largement comarqué. À la réception d’un code 401 status qui indique un défi, une application peut récupérer le graphique et le texte de cobranding. Récupérez une URL pour le graphique de cobranding en appelant WinHttpQueryOption avec l’indicateur WINHTTP_OPTION_PASSPORT_COBRANDING_URL. Récupérez le texte de cobranding en appelant WinHttpQueryOption avec l’indicateur WINHTTP_OPTION_PASSPORT_COBRANDING_TEXT. Ces éléments peuvent être utilisés pour personnaliser une boîte de dialogue de collecte d’informations d’identification.
Noms d’utilisateur et mots de passe stockés
Windows XP a introduit le concept de noms d’utilisateur et de mots de passe stockés. Si les informations d’identification Passport d’un utilisateur sont enregistrées via l’Assistant Inscription de passeport ou la boîte de dialogue d’informations d’identification standard, elles sont enregistrées dans les noms d’utilisateur et mots de passe stockés. Lors de l’utilisation de WinHTTP sur Windows XP ou version ultérieure, WinHTTP utilise automatiquement les informations d’identification dans les noms d’utilisateur et mots de passe stockés si les informations d’identification ne sont pas définies explicitement. Cela est similaire à la prise en charge des informations d’identification d’ouverture de session par défaut pour NTLM/Kerberos. Toutefois, l’utilisation des informations d’identification Passport par défaut n’est pas soumise aux paramètres de stratégie d’ouverture de session automatique.
Désactivation de l’authentification passport
Certaines applications peuvent nécessiter la possibilité de désactiver l’authentification Passport. Par exemple, lorsqu’un affilié Passport répond avec le code 302 status initial, il peut être préférable de suivre la redirection indiquée et de restituer la page d’authentification HTML Passport plutôt que de permettre à WinHTTP de gérer l’authentification en interne. L’authentification Passport est désactivée dans WinHTTP en appelant la fonction WinHttpSetOption avec l’option WINHTTP_OPTION_CONFIGURE_PASSPORT_AUTH et en transmettant la valeur WINHTTP_DISABLE_PASSPORT_AUTH. Il peut être réactivé ultérieurement avec WINHTTP_ENABLE_PASSPORT_AUTH.
L’authentification Passport ne peut pas être désactivée lors de l’utilisation de l’objet WinHttpRequest .
Comme indiqué plus haut dans cette section, l’authentification Passport est désactivée par défaut dans WinHTTP 5.1 et doit être explicitement activée avec WinHttpSetOption avant l’utilisation.
Remplacements de configuration Passport utilisés pour les tests
WinHTTP s’appuie sur les informations de configuration qu’il télécharge à partir du serveur nexus passport pour prendre en charge l’authentification Passport 1.4. Par défaut, ce serveur sécurisé (SSL) est nexus.passport.com, et la ressource de configuration est rdr/pprdr.asp, ce qui est connu sous le nom de configuration de passeport « live ». Le format des informations est un en-tête HTTP personnalisé « PassportURLs », suivi de paires attribut-valeur délimitées par des virgules.
Par exemple, «https://nexus.passport.com/rdr/pprdr.asp" ; retourne les informations de configuration suivantes :
PassportURLs: DARealm=Passport.net,
DALogin=login.passport.com/login2.asp,
DAReg=https://register.passport.com/defaultwiz.asp,
Properties=https://memberservices.passport.com/ppsecure/MSRV_EditProfile.asp,
Privacy=https://www.passport.com/consumer/privacypolicy.asp,
GeneralRedir=https://nexusrdr.passport.com/redir.asp,
Help=https://memberservices.passport.com/UI/MSRV_UI_Help.asp,
ConfigVersion=2
\r\n
Les composants pertinents pour WinHTTP sont DARealm, DALogin et ConfigVersion. Pour des raisons de performances, ils sont mis en cache pendant la durée de vie d’une session WinHTTP. Ces trois valeurs peuvent être remplacées par des applications qui sont requises pour fonctionner avec une autre infrastructure de passeport autre que la configuration de production « en direct » en modifiant les paramètres de Registre appropriés sous
HKEY_LOCAL_MACHINE
SOFTWARE
Microsoft
Windows
CurrentVersion
Internet Settings
WinHttp
Passport Test
LoginServerRealm (REG_SZ) For example: abc.net
LoginServerUrl (REG_SZ) For example: https://private-login.passport.com/login2.asp
ConfigVersion (REG_DWORD) For example: 10
Si LoginServerUrl est présent dans le Registre, WinHTTP ne contacte pas le serveur nexus pour obtenir d’autres valeurs de configuration. Dans ce cas, LoginServerRealm et ConfigVersion doivent également être définis via le Registre pour corriger les valeurs.
Une application peut, à des fins de test, être nécessaire pour télécharger la configuration passport à partir d’un serveur nexus privé. Pour ce faire, vous pouvez remplacer deux valeurs de Registre sous
HKEY_LOCAL_MACHINE
SOFTWARE
Microsoft
Windows
CurrentVersion
Internet Settings
WinHttp
Passport Test
NexusHost (REG_SZ) e.g. private-nexus.passport.com
NexusObj(REG_SZ) e.g. config/passport.asp
Rubriques connexes
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour