Encontré una solución para no poder ingresar http://127.0.0.1:35001 como la URL de ACS en la página de la aplicación GSuite SAML. La consola de administración de Google solo realiza la validación del lado del cliente para el requisito de https, por lo que puede usar la consola de Chrome para monitorear la llamada de red realizada al modificar la URL de ACS.

Luego, puede copiar esto como un comando curl y cambiar https a http

@Ted Schroeder—

Enfoque anterior (o simplemente Google no funciona)

Acabo de usar un proxy inverso:

 mitmproxy \ --listen-port 35000 \ --mode 'reverse:http://127.0.0.1:35001' \ --set keep_host_header=true

Si cambia la URL de ACS de Google SAML para que sea https://127.0.0.1:35000 y hace clic en "Probar inicio de sesión SAML", Google lo llevará a https://127.0.0.1:35000 , cuyo tráfico se redirigirá a http:/ /127.0.0.1:35001 . En el navegador me sale:

 Authentication details received, processing details. You may close this window at any time.

Sin embargo, al usar la extensión SAML-tracer, descubrí que había una discrepancia de URL ( https://127.0.0.1:35000 vs. http://127.0.0.1:35001 ). Parece que el cliente VPN de AWS está transmitiendo su URL esperada como http://127.0.0.1:35001 . Así que esto no parece viable.

Enfoque actual (o Auth0+Google funciona)

¡Intenté usar Auth0 en su lugar y lo hice funcionar! Hay algunos aros: por ejemplo, cree una nueva aplicación Auth0, vaya a Complementos y habilite la aplicación web SAML2, configure la URL de devolución de llamada de la aplicación en http://127.0.0.1:35001 y luego, en Configuración, use lo siguiente:

 { "audience": "urn:amazon:webservices:clientvpn", "mappings": { "user_id": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", "email": "NameID", "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", "given_name": "FirstName", "family_name": "LastName", "upn": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", "groups": "memberOf" }, "binding": "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect", "signResponse": true }

Luego, los usuarios, si descargan la configuración de VPN de AWS y usan la aplicación AWS VPN Client, serán llevados a una pantalla de inicio de sesión de Auth0 donde pueden iniciar sesión a través de Google. ¡Voila! (Y luego, por seguridad, debe agregar Reglas Auth0 para otorgar autorización solo a ciertos usuarios/grupos).

Todavía no tengo una respuesta completa, pero tengo los inicios de una y, de hecho, superé el error 403 anterior. La clave de todo esto se puede encontrar en la información de AWS Client VPN aquí: https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/client-authentication.html

Busque la sección titulada "Información del proveedor de servicios para crear una aplicación".

La clave es que estos son la URL de ACS y el ID de entidad que deben usarse. Desafortunadamente, G Suite no le permitirá establecer la URL de ACS en una URL que no sea https y, aparentemente, la aplicación AWS Client VPN no proporcionará una URL segura para la URL de ACS (donde va la respuesta de autenticación SAML).

Por lo tanto, si configura la ID de la entidad en "urn:amazon:webservices:clientvpn" y tiene la aplicación G Suite SAML según las instrucciones, superará el 403. Sin embargo, dado que la URL de ACS no se puede especificado, recibe cualquier mensaje de error que probablemente obtenga de la URL de ACS a la que se dirige la respuesta de autenticación.

Escenario de ejemplo

• Si lo configura en https://signon.aws.amazon.com/saml" como lo haría con AWS Console SSO, obtendrá un error del inicio de sesión de AWS que indica que la respuesta de SAML no es válida.
• Y si lo configura en https://127.0.0.1:35001 , recibirá un mensaje del navegador que indica que el "sitio no puede proporcionar una conexión segura".

Si alguien va más allá con esto, me encantaría saberlo. Mientras tanto, buscaré clientes OpenVPN que no sean de AWS que en realidad podrían admitir G Suite como IdP de SAML.

@alexandergunnarson

Como no tengo la capacidad de comentar (muchas gracias por hacer que este desbordamiento de pila sea fácil), tuve que editar mi respuesta para pasar los censores.

Desafortunadamente, no tenemos, y probablemente no tendremos durante algún tiempo, G Suite Enterprise porque es demasiado costoso para nuestro entorno de inicio. Entonces OIDP no es una opción viable para nosotros ahora. Pensé que esto funcionaría. Es bueno saber que lo hace.