Recientemente, un cliente solicitó a CSS que implementara una solución de federación AD FS 2.0 (ADFS) para satisfacer un requisito de seguridad muy singular asociado a escenarios de acceso externo a servicios alojados internamente.
- Requisito de seguridad: la política del cortafuegos del cliente NO permite el tráfico de red en el puerto TCP 443 desde la DMZ a la red interna. Todo el tráfico HTTPS debe utilizar puertos alternativos desde la DMZ a la red interna. Esto significa que el servidor proxy ADFS en la DMZ no podría utilizar el puerto estándar HTTPS TCP 443 para la comunicación con el servidor de federación ADFS en la red interna.
- Soluciones propuestas- En general, existen dos soluciones para cumplir este requisito de seguridad al tiempo que se satisfacen los requisitos de la ADFS.
Para obtener información adicional sobre los requisitos de ADFS relacionados, consulte: Uso de un proxy de terceros como sustituto de un proxy de servidor de federación AD FS 2.0 https://technet.microsoft.com/en-us/library/hh852618(v=ws.10).aspx
La primera solución consiste en que los dispositivos de red se encarguen exclusivamente de la asignación de puertos sin cambiar los puertos del servidor proxy ADFS ni del servidor ADFS. En otras palabras, todos los componentes participantes de ADFS siguen utilizando el puerto HTTPS 443 estándar como de costumbre.
El siguiente diagrama muestra la vista lógica de la primera solución:
Hemos desplegado con éxito esta solución en el entorno de producción del cliente. Sin embargo, esta solución depende de cómo los dispositivos de red específicos manejan la asignación de puertos, no vamos a entrar en eso aquí, pero en su lugar mostrar una solución alternativa.
La segunda solución consiste en aprovechar una opción de configuración de servidor proxy ADFS "out of the box" (OOTB) que consiste en utilizar un "servidor proxy HTTP" al enviar solicitudes al servidor ADFS.
El siguiente diagrama muestra la vista lógica de la segunda solución:
El siguiente diagrama muestra la opción de configuración del servidor proxy ADFS:
En esta solución configuramos el servidor proxy ADFS para "Utilizar un servidor proxy HTTP al enviar solicitudes a este Servicio de federación". A continuación, se puede especificar un puerto alternativo (por ejemplo, 8080) para llegar a un servidor proxy HTTP de la red interna.
Para obtener información adicional, consulte: Configurar un equipo para la función de proxy del servidor de federación: https://technet.microsoft.com/en-us/library/dd807067(v=ws.10).aspx
Los procedimientos de configuración sugeridos para validar esta segunda solución en su entorno incluyen:
- Instale un "sniffer" de red, por ejemplo WireShark(https://www.wireshark.org/), que pueda ver el tráfico desde el proxy ADFS hacia la red interna. Utilízalo para recopilar los mensajes de solicitud y respuesta durante el proceso de configuración.
- Antes de configurar el servidor proxy ADFS con la opción de servidor proxy HTTP, configure directamente Internet Explorer (IE) en el proxy ADFS para que utilice el servidor proxy HTTP:
En el servidor proxy ADFS, configure IE para que utilice un proxy:
IE > herramientas > opciones de internet > [conexiones] > Configuración de LAN > Servidor proxy > [avanzado]
Utilice IE para solicitar metadatos de federación al servidor ADFS (https://adfs.example.com/FederationMetadata/2007-06/FederationMetadata.xml ) para validar el correcto funcionamiento y que no se produzcan advertencias de certificados SSL .
Para ver más detalles del tráfico que sale del proxy ADFS puede utilizar un proxy local capaz de descifrar HTTPS, como Fiddler(https://www.fiddler2.com/). Usando esta herramienta puedes observar el flujo HTTP tanto desde IE como desde el propio proxy ADFS.
Asegúrate de habilitar la herramienta para conectarse al proxy HTTP, en Fiddler esto se logra usando la opción "chain to upstream gateway".
Fiddler > herramientas > opciones de fiddler > Conexiones > [x] cadena a puerta de enlace ascendente
Normalmente, también tendrá que desactivar Channel Binding en el servidor ADFS para que la autenticación se realice correctamente.
El componente proxy HTTP se comporta como un "hombre en el medio" en implementaciones AD FS 2.0. IIS en el servidor AD FS 2.0 protege automáticamente contra ataques de hombre en el medio utilizando un Channel Binding Token (CBT).
Para obtener información adicional sobre CBT y Extended Protection for Authentication, consulte: Escenarios compatibles y requisitos previos de Forefront UAG y AD FS 2.0 https://technet.microsoft.com/en-us/library/gg470 578.aspx
Configuración de opciones avanzadas para AD FS 2.0 https://technet.microsoft.com/en-us/library/hh237448%28WS.10%29.aspx
- Notas técnicas adicionales
Al descodificar la sesión SSL con Fiddler, uno debería ser capaz de rastrear el flujo de federación observando el mensaje de texto claro a través de Fiddler.
Ejemplo 1:
El servidor proxy ADFS recopila las credenciales del usuario presentando la página de inicio de sesión. Una vez que el usuario envía las credenciales, el servidor proxy ADFS solicita un token de seguridad en nombre de un usuario realizando una llamada HTTP POST de servicio web al servidor ADFS. Junto con la solicitud, el servidor proxy ADFS inserta las credenciales recopiladas en el elemento Username Token del siguiente mensaje SOAP:
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>
Ejemplo 2:
En un escenario de acceso SAML 2.0, el servidor proxy ADFS recibe una solicitud de autenticación SAML y, a continuación, realiza una llamada HTTP POST de servicio web al servidor ADFS. Junto con la solicitud, el servidor proxy ADFS insertará la solicitud de autenticación SAML en el mensaje SOAP como se indica a continuación:
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>
