Récemment, un client a demandé à CSS de mettre en œuvre une solution de fédération AD FS 2.0 (ADFS) pour répondre à une exigence de sécurité très particulière associée à des scénarios d'accès externe à des services hébergés en interne.
- Exigence de sécurité - La politique de pare-feu du client n'autorise PAS le trafic réseau sur le port TCP 443 depuis la zone démilitarisée vers le réseau interne. Tout le trafic HTTPS doit utiliser d'autres ports de la DMZ vers le réseau interne. Cela signifie que le serveur proxy ADFS dans la DMZ ne peut pas utiliser le port TCP 443 HTTPS standard pour communiquer avec le serveur de fédération ADFS dans le réseau interne.
- Solutions proposées - D'une manière générale, il existe deux solutions pour répondre à cette exigence de sécurité tout en respectant les exigences de l'ADFS.
Pour plus d'informations sur les exigences liées à l'ADFS, veuillez vous référer à : Utilisation d'un proxy tiers en remplacement d'un proxy de serveur de fédération AD FS 2.0 https://technet.microsoft.com/en-us/library/hh852618(v=ws.10).aspx
La première solution consiste à faire en sorte que les périphériques réseau gèrent exclusivement le mappage des ports sans modifier les ports du serveur proxy ADFS et du serveur ADFS. En d'autres termes, tous les composants participant à l'ADFS utilisent toujours le port HTTPS 443 comme d'habitude.
Le diagramme suivant montre la vue logique de la première solution :
Nous avons déployé avec succès cette solution dans l'environnement de production du client. Cependant, cette solution dépend de la manière dont les périphériques réseau spécifiques gèrent le mappage des ports, nous n'aborderons pas ce point ici, mais nous présenterons une solution alternative.
La deuxième solution consiste à tirer parti d'une option de configuration du serveur proxy ADFS prête à l'emploi (OOTB), qui consiste à utiliser un "serveur proxy HTTP" lors de l'envoi de requêtes au serveur ADFS.
Le diagramme suivant montre la vue logique de la deuxième solution :
Le diagramme suivant montre l'option de configuration du serveur proxy ADFS :
Dans cette solution, nous configurons le serveur proxy ADFS pour "Utiliser un serveur proxy HTTP lors de l'envoi de requêtes à ce service de fédération". Un autre port (par exemple 8080) peut alors être spécifié pour atteindre un serveur proxy HTTP dans le réseau interne.
Pour plus d'informations, veuillez vous référer à : Configurer un ordinateur pour le rôle de proxy du serveur de fédération : https://technet.microsoft.com/en-us/library/dd807067(v=ws.10).aspx
Les procédures de configuration suggérées pour valider cette deuxième solution dans votre environnement sont les suivantes :
- Installez un "renifleur" de réseau, par exemple WireShark(https://www.wireshark.org/), qui peut voir le trafic du proxy ADFS vers le réseau interne. Utilisez-le pour recueillir les messages de demande et de réponse pendant le processus de configuration.
- Avant de configurer le serveur proxy ADFS avec l'option serveur proxy HTTP, configurez directement internet explorer (IE) sur le proxy ADFS pour utiliser le serveur proxy HTTP :
Sur le serveur proxy ADFS, configurez IE pour qu'il utilise un proxy :
IE > outils > options internet > [connexions] > paramètres LAN > serveur proxy > [avancé]
Utilisez IE pour demander des métadonnées de fédération au serveur ADFS (https://adfs.example.com/FederationMetadata/2007-06/FederationMetadata.xml ) afin de valider le bon fonctionnement et l'absence d'avertissement concernant le certificat SSL .
Pour voir plus de détails sur le trafic sortant du proxy ADFS, vous pouvez utiliser un proxy local capable de décrypter HTTPS, tel que Fiddler(https://www.fiddler2.com/). En utilisant cet outil, vous pouvez observer le flux HTTP à partir d'IE et du proxy ADFS lui-même.
Veillez à permettre à l'outil de se connecter au proxy HTTP. Dans Fiddler, cela se fait à l'aide de l'option "chain to upstream gateway" (chaîne vers la passerelle en amont).
Fiddler > tools > fiddler options > Connections > [x] chain to upstream gateway
Normalement, vous devrez également désactiver le Channel Binding sur le serveur ADFS pour que l'authentification réussisse.
Le composant proxy HTTP se comporte comme un "homme du milieu" dans les déploiements AD FS 2.0. IIS sur le serveur AD FS 2.0 protège automatiquement contre les attaques de l'homme du milieu à l'aide d'un jeton de liaison de canal (CBT).
Pour plus d'informations sur CBT et Extended Protection for Authentication, veuillez vous référer à : Forefront UAG et AD FS 2.0 - Scénarios pris en charge et conditions préalables https://technet.microsoft.com/en-us/library/gg470578.aspx
Configuration des options avancées pour AD FS 2.0 https://technet.microsoft.com/en-us/library/hh237448%28WS.10%29.aspx
- Notes techniques supplémentaires
En décodant la session SSL avec Fiddler, on devrait pouvoir retracer le flux de la fédération en observant le message en texte clair via Fiddler.
Exemple 1 :
Le serveur mandataire ADFS recueille les informations d'identification de l'utilisateur en présentant la page de connexion. Une fois que l'utilisateur a soumis ses informations d'identification, le serveur mandataire ADFS demande un jeton de sécurité au nom de l'utilisateur en effectuant un appel HTTP POST de service web au serveur ADFS. En même temps que la demande, le serveur mandataire ADFS insère les informations d'identification recueillies dans l'élément Username Token du message SOAP ci-dessous :
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>
Exemple 2 :
Dans un scénario d'accès SAML 2.0, le serveur mandataire ADFS reçoit une demande d'authentification SAML, puis effectue un appel HTTP POST au serveur ADFS. Avec la demande, le serveur mandataire ADFS insère la demande d'authentification SAML dans le message SOAP, comme indiqué ci-dessous :
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>
