|Integrierte Proxy-Authentifizierung: Dienstkonten und Identitätsübernahme

„Meine Windows-Anmeldeinformationen verwenden“ braucht ein Subjekt. In einem Desktop-Programm kann das die Person sein, die es ausführt. In einem Dienst kann das das Konto des Dienstes sein. In einer Webanwendung ersetzt die erfolgreiche Anmeldung eines Besuchers nicht automatisch den Sicherheitskontext der ausgehenden Anforderung.

Das erklärt, warum ein Browser und serverseitiger Code auf derselben Maschine unterschiedliche Ergebnisse von einem Proxy mit integrierter Authentifizierung erhalten können. Sie stellen möglicherweise unterschiedliche Identitäten vor.

Benennen Sie die Identitäten, bevor Sie den Code ändern

• Die Person, die im Desktop-Browser angemeldet ist.
• Das Konto, das den Anwendungsprozess hostet.
• Jede für den ausgehenden Vorgang aktive übernommene Identität.
• Das Konto, das der Proxy tatsächlich akzeptiert oder abgelehnt hat.

Auf den von .NET unterstützten Pfaden der integrierten Authentifizierung betrifft DefaultCredentials den aktuellen Sicherheitskontext. Es ist kein globaler Alias für jeden, der eine Seite auf einer anderen Maschine geöffnet hat.

Wenn das Produkt bewusst als Benutzer handelt, brauchen Identitätsübernahme und etwaige Anforderungen an die Netzwerkdelegierung ein eigenes unterstütztes Design. Einen allgemeinen Schalter zur Verwendung von Standardanmeldeinformationen einzuschalten, begründet dieses Design nicht. Umgekehrt sollte ein Hintergrundauftrag, der als Dienstidentität laufen soll, nicht davon abhängen, dass jemand zuerst einen Browser öffnet.

Vergleichen Sie den interaktiven und den bereitgestellten Start ohne Geheimnisse: Kontokontext, Proxy-Endpunkt, angekündigte Methode und abgelehnte Identität. Vermeiden Sie es, ein Desktop-Passwort in die Anwendung zu kopieren, nur weil dadurch eine einmalige Anforderung erfolgreich war. Konfigurieren Sie das Konto, das die Anwendung verwenden soll, und halten Sie diese Zuständigkeit im Bereitstellungsprotokoll sichtbar.