Kürzlich wurde CSS von einem Kunden gebeten, eine AD FS 2.0 (ADFS)-Föderationslösung zu implementieren, um eine sehr spezielle Sicherheitsanforderung im Zusammenhang mit Szenarien des externen Zugriffs auf intern gehostete Dienste zu erfüllen.
- Sicherheitsanforderung - Die Firewall-Richtlinie des Kunden erlaubt KEINEN Netzwerkverkehr über TCP-Port 443 von der DMZ zum internen Netzwerk. Der gesamte HTTPS-Verkehr muss alternative Ports von der DMZ zum internen Netzwerk verwenden. Dies bedeutet, dass der ADFS-Proxyserver in der DMZ nicht den Standard-HTTPS-TCP-Port 443 für die Kommunikation mit dem ADFS-Verbundserver im internen Netzwerk verwenden kann.
- Vorgeschlagene Lösungen - Im Allgemeinen gibt es zwei Lösungen, um diese Sicherheitsanforderung zu erfüllen und gleichzeitig die ADFS-Anforderungen zu erfüllen.
Weitere Informationen zu den entsprechenden ADFS-Anforderungen finden Sie unter: Verwendung eines Proxy eines Drittanbieters als Ersatz für einen AD FS 2.0 Federation Server Proxy https://technet.microsoft.com/en-us/library/hh852618(v=ws.10).aspx
Die erste Lösung besteht darin, dass die Netzwerkgeräte ausschließlich die Portzuordnung vornehmen, ohne die Ports auf dem ADFS-Proxyserver und dem ADFS-Server zu ändern. Mit anderen Worten, alle teilnehmenden ADFS-Komponenten verwenden wie gewohnt den Standard-HTTPS-Port 443.
Das folgende Diagramm zeigt die logische Darstellung der ersten Lösung:
Wir haben diese Lösung erfolgreich in der Produktionsumgebung des Kunden implementiert. Diese Lösung hängt jedoch davon ab, wie bestimmte Netzwerkgeräte die Portzuordnung handhaben. Darauf gehen wir hier nicht ein, sondern zeigen stattdessen eine alternative Lösung.
Die zweite Lösung ist die Nutzung einer standardmäßigen (OOTB) ADFS-Proxy-Server-Konfigurationsoption, die die Verwendung eines "HTTP-Proxy-Servers" beim Senden von Anfragen an den ADFS-Server vorsieht.
Das folgende Diagramm zeigt die logische Darstellung der zweiten Lösung:
Das folgende Diagramm zeigt die Konfigurationsmöglichkeiten des ADFS-Proxyservers:
Bei dieser Lösung wird der ADFS-Proxyserver so konfiguriert, dass "beim Senden von Anfragen an diesen Federation Service ein HTTP-Proxyserver verwendet wird". Ein alternativer Port (z. B. 8080) kann dann angegeben werden, um einen HTTP-Proxy-Server im internen Netzwerk zu erreichen.
Weitere Informationen finden Sie unter: Konfigurieren Sie einen Computer für die Federation Server Proxy-Rolle: https://technet.microsoft.com/en-us/library/dd807067(v=ws.10).aspx
Zur Validierung dieser zweiten Lösung in Ihrer Umgebung werden folgende Konfigurationsverfahren vorgeschlagen:
- Installieren Sie einen Netzwerk-"Sniffer", z. B. WireShark(https://www.wireshark.org/), der den Datenverkehr vom ADFS-Proxy in Richtung des internen Netzwerks beobachten kann. Verwenden Sie dies, um die Anfrage- und Antwortmeldungen während des Konfigurationsprozesses zu sammeln.
- Bevor Sie den ADFS-Proxyserver mit der Option HTTP-Proxyserver konfigurieren, konfigurieren Sie den Internet Explorer (IE) auf dem ADFS-Proxyserver direkt so, dass er den HTTP-Proxyserver verwendet:
Konfigurieren Sie den IE auf dem ADFS-Proxyserver für die Verwendung eines Proxys:
IE > Extras > Internetoptionen > [Verbindungen] > LAN-Einstellungen > Proxy-Server > [Erweitert]
Verwenden Sie den IE, um Verbund-Metadaten vom ADFS-Server anzufordern (https://adfs.example.com/FederationMetadata/2007-06/FederationMetadata.xml ), um den ordnungsgemäßen Betrieb zu überprüfen und sicherzustellen, dass keine SSL Zertifikatswarnungen ausgegeben werden.
Um mehr Details über den vom ADFS-Proxy ausgehenden Datenverkehr zu erfahren, können Sie einen lokalen Proxy verwenden, der HTTPS entschlüsseln kann, z. B. Fiddler(https://www.fiddler2.com/). Mit diesem Tool können Sie den HTTP-Datenfluss sowohl vom IE als auch vom ADFS-Proxy selbst beobachten.
Stellen Sie sicher, dass das Tool eine Verbindung zum HTTP-Proxy herstellen kann. In Fiddler wird dies mit der Option "chain to upstream gateway" erreicht.
Fiddler > tools > fiddler options > Connections > [x] chain to upstream gateway
Damit die Authentifizierung erfolgreich ist, müssen Sie normalerweise auch die Kanalbindung auf dem ADFS-Server deaktivieren.
Die HTTP-Proxy-Komponente verhält sich in AD FS 2.0-Bereitstellungen wie ein "Mann in der Mitte". IIS auf dem AD FS 2.0-Server schützt automatisch vor Man-in-the-Middle-Angriffen mit einem Channel Binding Token (CBT).
Weitere Informationen zu CBT und Extended Protection for Authentication finden Sie unter: Unterstützte Szenarien und Voraussetzungen für Forefront UAG und AD FS 2.0 https://technet.microsoft.com/en-us/library/gg470 578.aspx
Konfigurieren der erweiterten Optionen für AD FS 2.0 https://technet.microsoft.com/en-us/library/hh237448%28WS.10%29.aspx
- Zusätzliche technische Hinweise
Wenn man die SSL Sitzung mit Fiddler entschlüsselt, sollte man in der Lage sein, den Föderationsfluss zu verfolgen, indem man die Klartextnachricht über Fiddler beobachtet.
Beispiel 1:
Der ADFS-Proxy-Server sammelt die Anmeldedaten des Benutzers, indem er die Anmeldeseite anzeigt. Sobald der Benutzer die Anmeldedaten eingegeben hat, fordert der ADFS-Proxy-Server ein Sicherheitstoken im Namen des Benutzers an, indem er einen HTTP-POST-Aufruf für einen Webdienst an den ADFS-Server richtet. Zusammen mit der Anforderung fügt der ADFS-Proxy-Server die gesammelten Anmeldedaten in das Element Username Token in der unten stehenden SOAP-Nachricht ein:
POST https://adserver.jacob.com/adfs/services/trust/proxytrust HTTP/1.1
<s:Envelope xmlns:s=”https://www.w3.org/2003/05/soap-envelope” xmlns:a=”https://www.w3.org/2005/08/addressing” xmlns:u=”https://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd”>
<s:Header> ….
<s:Body>
<t:RequestSecurityToken xmlns:t=”https://schemas.xmlsoap.org/ws/2005/02/trust”>
<ReplyTo xmlns=”https://schemas.microsoft.com/ws/2008/06/identity” />
<wsp:AppliesTo xmlns:wsp=”https://schemas.xmlsoap.org/ws/2004/09/policy”>
<wsa:EndpointReference xmlns:wsa=”https://www.w3.org/2005/08/addressing”>
<wsa:Address>microsoft:identityserver:https://adfs.example.com/adfs/services/trust</wsa:Address>
</wsa:EndpointReference>
</wsp:AppliesTo>
<t:KeyType>https://schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey</t:KeyType>
<t:OnBehalfOf>
<UsernameToken u:Id=”uuid-6cdb82dc-1b05-45e6-8b6b-d17c5bbf123c-26″ xmlns=”https://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd”>
<Username>jakec</Username>
<Password Type=”https://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText”>mypassword</Password>
</UsernameToken>
</t:OnBehalfOf>
<t:RequestType>https://schemas.xmlsoap.org/ws/2005/02/trust/Issue</t:RequestType>
<t:TokenType>https://schemas.microsoft.com/ws/2006/05/servicemodel/tokens/SecureConversation</t:TokenType>
<ActivityId xmlns=”https://schemas.microsoft.com/ws/2009/12/identityserver/”>355bd888-cb90-4367-8428-1cc473c6b717</ActivityId>
<MSISSession xmlns=”https://schemas.microsoft.com/ws/2009/12/identityserver/”>
<WsFederationData />
</MSISSession>
</t:RequestSecurityToken>
</s:Body>
</s:Envelope>
Beispiel 2:
Bei einem SAML 2.0-Zugangsszenario empfängt der ADFS-Proxy-Server eine SAML-Authentifizierungsanforderung und führt dann einen HTTP-POST-Webdienstaufruf an den ADFS-Server durch. Zusammen mit der Anforderung fügt der ADFS-Proxyserver die SAML-Authentifizierungsanforderung in die SOAP-Nachricht ein (siehe unten):
POST https://adserver.jacob.com/adfs/services/trust/samlprotocol/proxytrust HTTP/1.1
<s:Envelope xmlns:s=”https://www.w3.org/2003/05/soap-envelope” xmlns:a=”https://www.w3.org/2005/08/addressing” xmlns:u=”https://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd”>
<s:Header> ….
<s:Body>
<msis:IssueRequest xmlns:msis=”https://schemas.microsoft.com/ws/2009/12/identityserver/samlprotocol/”>
<msis:ActivityId>355bd888-cb90-4367-8428-1cc473c6b717</msis:ActivityId>
<msis:Message>
<msis:BaseUri>https://adfs.example.com:443/adfs/ls/</msis:BaseUri>
<msis:SAMLRequest>fVcxTsMwFNz7FZb3xnaDG/…/H1R9wU=</msis:SAMLRequest>
<msis:RedirectBindingInformation>
<msis:RelayState>7fddabbeb1eda2be86416de69fbc8780c23809e3</msis:RelayState>
<msis:Signature>…./ocz7JZZnAloxjpFhFCKM6MbY3io=</msis:Signature>
<msis:SigAlg>https://www.w3.org/2000/09/xmldsig#rsa-sha1</msis:SigAlg>
<msis:QueryStringHash>c/8gJhcw98xYY+D/yQa5RU4KwXQ=</msis:QueryStringHash>
</msis:RedirectBindingInformation>
</msis:Message>
<msis:OnBehalfOf>
<SecurityContextToken u:Id=”_4ba3e1a4-cd96-470a-aa64-2d7c8431c3e3-BE4548F70EA0675E553AD9904F63C39F” xmlns=”https://docs.oasis-open.org/ws-sx/ws-secureconversation/200512″>
<Identifier>urn:uuid:91d45e23-508c-409e-a04a-c40f8d696c60</Identifier>
<Instance>urn:uuid:54c1ae12-492e-48e9-8b59-db8d4031d6c5</Instance>
<Cookie xmlns=”https://schemas.microsoft.com/ws/2006/05/security”>sc7Wn1l1ylzr18EQM2WgK2uvztHbSB….3nIuRCbXowdPRaDU9stlXKNfA99vD</Cookie>
</SecurityContextToken>
</msis:OnBehalfOf>
<msis:SessionState />
</msis:IssueRequest>
</s:Body>
</s:Envelope>
