Servicio central de autenticación que redirige al subdominio, usando la firma digital como token de autenticación

He visto un esquema muy similar al tuyo utilizado en la práctica, aunque con un secreto MAC compartido donde tienes una clave pública / privada. No lo recomendaría, me parece incómodo. Perdóneme si voy muy lejos, pero viendo sus resultados, creo que no es un programador del lado del servidor. Parece que los programadores de subdominios del lado del servidor son sus principales clientes aquí; usted quiere ayudarlos con su servidor central de autenticación. Así que sugiero consultar a un programador de subdominios de este tipo e intentar comprender sus necesidades y hacer que su servicio sea muy fácil para ellos (sugerencia: el actual no lo es).

La falla principal es que esto es costoso, tanto en términos de tiempo de programación (en el servidor central y en los subdominios) como también computacionalmente.

Otra falla importante es que cuando el tiempo de espera expire, se necesitaría un código bastante complicado para permitir que el usuario vuelva a autenticarse y continuar sin perder su estado.

Vuelva a pensar en lo que hace su servicio. Mi contrapropuesta es que su servicio establece un estado del lado del servidor y lo entrega a los subdominios para que luego puedan usarlo internamente. El estado inicialmente consiste en user_id, authenticated_until, authorized_subdomains, pero, por supuesto, lo que no sea trivial que haga el subdominio, puede agregar sus propias cosas al mismo estado.

En la mayoría de los marcos que posiblemente pueda usar un subdominio, es probable que las sesiones se identifiquen con un token aleatorio (piense en algo como JSESSIONID o PHPSESSID ).

Solo una forma de exportar una sesión de central-auth a subdominio es:

1. El subdominio expone enlace con restricción de IP y verificación de certificado de cliente y servidor. Esto no requiere programación, solo tareas de configuración del servidor web (host virtual). Los navegadores de usuario y cualquier otra persona nunca podrían hablar con este puerto.
2. Un POST de servidor central para enlace el estado y un token aleatorio.
3. Ahora el subdominio usa este token para su almacenamiento de sesión normal.

No creo que esto sea óptimo, requiere menos programación y menos subdominio que su diseño. Una vez que piense en un estado de sesión, se le ocurren muchas posibilidades y marcos existentes.

Sub-respuestas específicas:

1. Estás proponiendo crear tu propio protocolo de autenticación.
2. No puedo pensar en ningún protocolo existente que responda a su caso de uso (incorrecto).
3. Sí, una "mala respuesta a la pregunta incorrecta", supongo.
4. Cada solicitud HTTP dentro de la aplicación web del subdominio donde el usuario está trabajando requiere alguna autenticación. No solo la solicitud HTTP externa inicial, sino también cada interna. Nada aquí causaría la actualización de la marca de tiempo / sig cuando el usuario está haciendo su trabajo normal. Después de algunos minutos, el usuario está perdiendo su estado en la aplicación web de un subdominio, ya sea que el usuario esté activo o no. Están perdiendo sus variables / objetos de sesión del lado del servidor. Si soluciona esto y pasa su token de sesión a través del servidor central de autenticación, se anularán todas las demás ideas; entonces, en primer lugar, no necesita su firma y los cálculos de clave pública / privada de propiedad.

Una cosa en la que puedo pensar que puede ser problemático (si el usuario está ENVIANDO al subdominio) es que no firma el subdominio al que el usuario intenta conectarse. Déjame intentar dar un ejemplo del problema:

Digamos que tengo credenciales (válidas) para foo.example.com . Envío (foo, username, password) a example.com/login y recupero (sig=signed(id, timestamp)) . Ahora POSTE a bar.example.com/login con (id, timestamp, sig) . bar.example.com/login verá sig , verificará que timestamp coincida con los datos firmados y luego ingrese el id que se firmó. Ahora estoy conectado a bar.example.com . Ups.

Por lo tanto, diría que no solo no es necesario que el usuario vea el sig , sino que otorgarle al usuario el sig es realmente un problema de seguridad. Si devuelve sig al usuario, debe hacer sig=signed(id, timestamp, subdomain) y el inicio de sesión del subdominio debe verificar que se trata del subdominio firmado.

Parece que el envío de usuario, pase y subdominio es la única autenticación que está realizando. Publicar en los otros dominios no me parece seguro en absoluto. He hecho esto en varios escenarios y para mí la validación del usuario y la contraseña, no importa cómo se haga esto es el servicio de "autenticación". Si desea segregar a los usuarios en diferentes subdominios, ¿por qué no utilizar la capacidad de proxy inverso de esencialmente un solo punto de entrada? Y, esto también puede actuar como un equilibrador de carga también. Estoy seguro al 99% de que puede lograr sus objetivos utilizando un servidor de proxy inverso y hacerlo de manera muy segura. He hecho esto para el estado de Carolina del Norte para una de las entidades gubernamentales.