Passport-Authentifizierung in WinHTTP
Microsoft Windows HTTP Services (WinHTTP) unterstützen die clientseitige Verwendung des Microsoft Passport-Authentifizierungsprotokolls vollständig. Dieses Thema bietet eine Übersicht über die Transaktionen, die an der Passport-Authentifizierung beteiligt sind, und deren Handhabung.
Hinweis
In WinHTTP 5.1 ist die Passport-Authentifizierung standardmäßig deaktiviert.
Passport 1.4
Passport ist eine Kernkomponente der Microsoft .NET-Bausteindienste. Es ermöglicht Unternehmen, verteilte Webdienste für eine Vielzahl von Anwendungen zu entwickeln und anzubieten, und ermöglicht es ihren Mitgliedern, einen Anmeldenamen und ein Kennwort auf allen teilnehmenden Websites zu verwenden.
WinHTTP bietet Plattformunterstützung für Microsoft Passport 1.4, indem das clientseitige Protokoll für die Passport 1.4-Authentifizierung implementiert wird. Sie befreit Anwendungen von den Details der Interaktion mit der Passport-Infrastruktur und den gespeicherten Benutzernamen und Kennwörtern in Windows XP. Durch diese Abstraktion unterscheidet sich die Verwendung von Passport aus Entwicklersicht nicht von der Verwendung herkömmlicher Authentifizierungsschemas wie Basic oder Digest.
Windows XP: Der Registrierungsschlüssel HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Passport\NumRegistrationRuns gibt an, wie oft der Passport-Authentifizierungs-Assistent angezeigt wird, wenn eine PassPort-Authentifizierung erforderlich ist. Wenn der Wert für diesen Schlüssel auf eine Zahl größer als 5 festgelegt ist, wird der Assistent nicht angezeigt.
In den folgenden Abschnitten werden die Transaktionen beschrieben, die an der Passport-Authentifizierung aus sicht einer Clientanwendung beteiligt sind. Informationen zur serverseitigen Passport-Entwicklung finden Sie in der Passport SDK-Dokumentation– Übersicht.
Anfängliche Anforderung
Wenn ein Client eine Ressource auf einem Server anfordert, die Passport-Authentifizierung erfordert, überprüft der Server die Anforderung auf das Vorhandensein von Tickets. Wenn mit der Anforderung ein gültiges Ticket gesendet wird, antwortet der Server mit der angeforderten Ressource. Wenn das Ticket auf dem Client nicht vorhanden ist, antwortet der Server mit einem 302 status Code. Die Antwort enthält den Anforderungsheader "WWW-Authenticate: Passport1.4". Clients, die Passport nicht verwenden, können der Umleitung zum Passport-Anmeldeserver folgen. Fortgeschrittenere Clients wenden sich in der Regel an den Passport-Nexus, um den Standort des Passport-Anmeldeservers zu ermitteln.
Hinweis
Im Mittelpunkt des Microsoft Passport-Netzwerks steht das Passport Nexus, das die Synchronisierung von Passport-Teilnehmerstandorten erleichtert, um sicherzustellen, dass jeder Standort über die neuesten Details zur Netzwerkkonfiguration und anderen Problemen verfügt. Jede Passport-Komponente (Passport-Manager, Anmeldeserver, Updateserver usw.) kommuniziert regelmäßig mit dem Nexus, um die Informationen abzurufen, die sie für die Suche und ordnungsgemäße Kommunikation mit den anderen Komponenten im Passport-Netzwerk benötigt. Diese Informationen werden als XML-Dokument abgerufen, das als Komponentenkonfigurationsdokument oder CCD bezeichnet wird.
Die folgende Abbildung zeigt die anfängliche Anforderung an ein Passport-Partnerunternehmen.
Passport-Anmeldeserver
Ein Passport-Anmeldeserver verarbeitet alle Anforderungen für Tickets für jede Ressource in einer Passport-Domänenautorität. Bevor eine Anforderung mit Passport authentifiziert werden kann, muss die Clientanwendung den Anmeldeserver kontaktieren, um die entsprechenden Tickets zu erhalten.
Wenn ein Client Tickets von einem Passport-Anmeldeserver anfordert, antwortet der Anmeldeserver in der Regel mit einem Code vom Typ 401 status, um anzugeben, dass Benutzeranmeldeinformationen angegeben werden müssen. Wenn diese Anmeldeinformationen bereitgestellt werden, antwortet der Anmeldeserver mit den Tickets , die für den Zugriff auf die angegebene Ressource auf dem Server erforderlich sind, der die ursprünglich angeforderte Ressource enthält. Der Anmeldeserver kann den Client auch an einen anderen Server umleiten, der die angeforderte Ressource bereitstellen kann.
Authentifizierte Anforderung
Wenn der Client über die Tickets verfügt, die einem bestimmten Server entsprechen, werden diese Tickets in allen Anforderungen an diesen Server enthalten. Wenn die Tickets seit dem Abrufen vom Passport-Anmeldeserver nicht geändert wurden und die Tickets für den Ressourcenserver gültig sind, sendet der Ressourcenserver eine Antwort, die sowohl die angeforderte Ressource als auch Cookies enthält, die angeben, dass der Benutzer für zukünftige Anforderungen authentifiziert ist.
Die zusätzlichen Cookies in der Antwort sollen den Authentifizierungsprozess beschleunigen. Zusätzliche Anforderungen in derselben Sitzung für Ressourcen auf Servern in derselben Passport Domain Authority enthalten diese zusätzlichen Cookies. Die Anmeldeinformationen müssen erst dann erneut an den Anmeldeserver gesendet werden, wenn die Cookies ablaufen.
Verwenden von Passport in WinHTTP
Die Passport-Authentifizierung in WinHTTP ist anderen Authentifizierungsschemas sehr ähnlich. Eine Übersicht über die Authentifizierung in WinHTTP finden Sie unter Authentifizierung in WinHTTP .
In WinHTTP 5.1 ist die Passport-Authentifizierung standardmäßig deaktiviert und muss vor der Verwendung explizit mit WinHttpSetOption aktiviert werden.
WinHTTP verarbeitet viele der Transaktionsdetails intern für die Passport-Authentifizierung. Während der ersten Anforderung antwortet der Server mit einem Code vom Typ 302 status, wenn eine Authentifizierung erforderlich ist. Der 302-status Code weist tatsächlich auf eine Umleitung hin und ist Aus Gründen der Abwärtskompatibilität Teil des Passport-Protokolls. WinHTTP blendet den 302-status-Code aus und kontaktiert den Passport-Nexus und dann den Anmeldeserver. Die WinHTTP-Anwendung wird über den code 401 status benachrichtigt, der vom Anmeldeserver zum Anfordern von Benutzeranmeldeinformationen gesendet wird. Für die Anwendung sieht es jedoch so aus, als ob der 401-status von dem Server stammt, von dem die Ressource angefordert wurde. Auf diese Weise ist die WinHTTP-Anwendung nicht von Interaktionen mit anderen Servern bekannt und kann die Passport-Authentifizierung mit demselben Code verarbeiten, der andere Authentifizierungsschemas verarbeitet.
In der Regel antwortet eine WinHTTP-Anwendung auf einen 401-status-Code, indem sie Anmeldeinformationen für die Authentifizierung angibt. Wenn Anmeldeinformationen mit WinHttpSetCredentials oder SetCredentials für die Passport-Authentifizierung bereitgestellt werden, werden die Anmeldeinformationen tatsächlich an den Anmeldeserver und nicht an den in der Anforderung angegebenen Server gesendet.
Wenn sie jedoch auf einen 407-status-Code reagiert, muss eine WinHTTP-Anwendung WinHttpSetOption verwenden, um Proxyanmeldeinformationen anstelle von WinHttpSetCredentials bereitzustellen. Da WinHttpSetOption eine weniger sichere Möglichkeit zum Bereitstellen von Anmeldeinformationen ist, sollte dies normalerweise vermieden werden.
Nach dem Abrufen werden Tickets intern verwaltet und in zukünftigen Anforderungen automatisch an die entsprechenden Server gesendet.
Hinweis
Mit WinHTTP können Sie die automatische Umleitung deaktivieren, indem Sie die WinHttpSetOption-Funktion für das flag WINHTTP_OPTION_DISABLE_FEATURE aufrufen und den Wert WINHTTP_DISABLE_REDIRECTS angeben. Das Deaktivieren der Umleitung beeinträchtigt nicht die Umleitung, die WinHTTP intern für Passport-Transaktionen verarbeitet.
WinHTTP kann die Passport-Authentifizierung auch dann erfolgreich abschließen, wenn eine Anwendung die automatische Umleitung deaktiviert. Nach Abschluss der Passport-Authentifizierung muss jedoch eine implizite Umleitung von der Passport-Anmeldeserver-URL zurück zur ursprünglichen URL erfolgen. Diese Umleitung wird nicht durch eine 302-HTTP-Antwort ausgelöst, sondern ist im Passport-Protokoll implizit.
WinHTTP behandelt diese implizite Umleitung speziell. Wenn eine Anwendung die automatische Umleitung deaktiviert hat, erfordert WinHTTP, dass die Anwendung WinHTTP die "Berechtigung" zur automatischen Umleitung in diesem speziellen Fall erteilt.
Damit WinHTTP nach der Authentifizierung zurück zur ursprünglichen URL umgeleitet werden kann, muss die Anwendung eine Rückruffunktion mit WinHttpSetStatusCallback registrieren. WinHTTP kann die Anwendung dann mit einem WINHTTP_CALLBACK_STATUS_REDIRECT-Rückruf benachrichtigen, wodurch die Anwendung die Umleitung abbrechen kann. Eine Anwendung muss keine Funktionen in der Rückruffunktion bereitstellen. Die Registrierung des Rückrufs reicht aus, damit WinHTTP diese Sonderfallumleitung befolgen kann.
Die ERROR_WINHTTP_LOGIN_FAILURE Meldung wird generiert, wenn keine Rückruffunktion von der Anwendung festgelegt wird.
Passport Cobranding
Im Gegensatz zu herkömmlichen Authentifizierungsschemas, die von WinHTTP unterstützt werden, kann Passport umfassend cobranded werden. Wenn sie einen 401-status Code erhalten, der eine Herausforderung angibt, kann eine Anwendung die Cobrandinggrafik und den Text abrufen. Rufen Sie eine URL für die Cobrandinggrafik ab, indem Sie WinHttpQueryOption mit dem flag WINHTTP_OPTION_PASSPORT_COBRANDING_URL aufrufen. Rufen Sie den Cobrandingtext ab, indem Sie WinHttpQueryOption mit dem flag WINHTTP_OPTION_PASSPORT_COBRANDING_TEXT aufrufen. Diese Elemente können verwendet werden, um ein Dialogfeld zum Sammeln von Anmeldeinformationen anzupassen.
Gespeicherte Benutzernamen und Kennwörter
Windows XP hat das Konzept der gespeicherten Benutzernamen und Kennwörter eingeführt. Wenn die Passport-Anmeldeinformationen eines Benutzers über den Passport-Registrierungs-Assistenten oder das Standarddialogfeld für Anmeldeinformationen gespeichert werden, werden sie unter Gespeicherte Benutzernamen und Kennwörter gespeichert. Bei Verwendung von WinHTTP unter Windows XP oder höher verwendet WinHTTP automatisch die Anmeldeinformationen in den gespeicherten Benutzernamen und Kennwörtern, wenn Anmeldeinformationen nicht explizit festgelegt sind. Dies ähnelt der Unterstützung von Standardanmeldeinformationen für NTLM/Kerberos. Die Verwendung der Standardmäßigen Passport-Anmeldeinformationen unterliegt jedoch nicht den Einstellungen für die automatische Anmeldung.
Deaktivieren der Passport-Authentifizierung
Einige Anwendungen erfordern möglicherweise die Möglichkeit, die Passport-Authentifizierung zu deaktivieren. Wenn z. B. ein Passport-Partner mit dem ersten 302-status-Code antwortet, kann es besser sein, der angegebenen Umleitung zu folgen und die HTML Passport-Authentifizierungsseite zu rendern, anstatt WinHTTP die interne Authentifizierung zuzulassen. Die Passport-Authentifizierung wird in WinHTTP deaktiviert, indem die WinHttpSetOption-Funktion mit der Option WINHTTP_OPTION_CONFIGURE_PASSPORT_AUTH aufgerufen und der Wert WINHTTP_DISABLE_PASSPORT_AUTH übergeben wird. Sie kann später mit WINHTTP_ENABLE_PASSPORT_AUTH wieder aktiviert werden.
Die Passport-Authentifizierung kann bei Verwendung des WinHttpRequest-Objekts nicht deaktiviert werden.
Wie bereits in diesem Abschnitt erwähnt, ist die Passport-Authentifizierung in WinHTTP 5.1 standardmäßig deaktiviert und muss vor der Verwendung explizit mit WinHttpSetOption aktiviert werden.
Für Tests verwendete Passport-Konfigurationsüberschreibungen
WinHTTP basiert auf den Konfigurationsinformationen, die vom Passport Nexus-Server heruntergeladen werden, um die Passport 1.4-Authentifizierung zu unterstützen. Standardmäßig ist dieser sichere (SSL)-Server nexus.passport.com, und die Konfigurationsressource ist rdr/pprdr.asp, was als "Live"-Passportkonfiguration bezeichnet wird. Das Format der Informationen ist ein benutzerdefinierter HTTP-Header "PassportURLs", gefolgt von kommagetrennten Attribut-Wert-Paaren.
Beispiel: "https://nexus.passport.com/rdr/pprdr.asp" gibt die folgenden Konfigurationsinformationen zurück:
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
Die für WinHTTP relevanten Teile sind DARealm, DALogin und ConfigVersion. Aus Leistungsgründen werden sie für die Lebensdauer einer WinHTTP-Sitzung zwischengespeichert. Diese drei Werte können von Anwendungen überschrieben werden, die erforderlich sind, um mit einer anderen Passport-Infrastruktur als dem "Live"-Produktionssetup zu arbeiten, indem sie die entsprechenden Registrierungseinstellungen unter ändern.
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
Wenn LoginServerUrl in der Registrierung vorhanden ist, kontaktiert WinHTTP den Nexusserver nicht, um andere Konfigurationswerte zu erhalten. In diesem Fall sollten LoginServerRealm und ConfigVersion auch über die Registrierung festgelegt werden, um Werte zu korrigieren.
Eine Anwendung kann zu Testzwecken erforderlich sein, um die Passport-Konfiguration von einem privaten Nexus-Server herunterzuladen. Dies kann durch Überschreiben von zwei Registrierungswerten unter
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
Zugehörige Themen
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für