authentication - tutorial - free coldfusion server

¿Cómo implemento un inicio de sesión único para diferentes aplicaciones ColdFusion que se ejecutan en el mismo servidor?

Question

Tengo varias aplicaciones de CF ejecutándose en el mismo servidor bajo el mismo nombre de dominio. Uno de ellos, llamémoslo Portal , está destinado a ser el inicio de sesión único para las otras aplicaciones, que podemos llamar Atlas y P-Body . Normalmente, debe establecer algunas variables en el ámbito de la session para manejar la información de inicio de sesión:

function Login()
{
session.auth = structNew();
session.auth.isLoggedIn = true;
session.auth.id = GetCurrentUserId();
}

Pero el alcance de la sesión solo se comparte en una aplicación, no en el servidor completo. Esto significa que cualquier usuario que inicie sesión en Portal permanecerá conectado, pero si intenta navegar a Atlas o P-Body , tendrá que iniciar sesión de nuevo.

En este caso, ¿cómo "compartiría" el alcance de la sesión para que todas las aplicaciones en un servidor puedan tener acceso a ella? La única forma que he podido encontrar es usar variables de cliente y establecer un almacén de datos para que se comparta entre las aplicaciones. Entonces el código se convierte en:

function Login()
{
client.auth = structNew();
client.auth.isLoggedIn = true;
client.auth.id = GetCurrentUserId();
}
function Logout()
{
structDelete(client, "auth");
}

Lo que hay que tener en cuenta aquí es que, dado que la variable del cliente no se borra al finalizar la sesión, tenemos que borrarla manualmente en el controlador OnSessionEnd .

¿Es esta la mejor manera de manejar el inicio de sesión único en ColdFusion? Si es así, ¿hay algún inconveniente al usar la variable del cliente o dificultades a tener en cuenta?

Actualización: Acabo de probar el método de variables del cliente y parece que solo el hitcount , timecreated , lastvisit y urltoken se comparten entre las aplicaciones, así que vuelvo al cuadrado 1.

Answer 1

El inicio de sesión único (SSO) no es una tarea fácil y existen varios productos muy costosos que ayudan a demostrarlo.

Afortunadamente, hay algunos proyectos gratuitos de OSS que están bien.

También hay muchas otras consideraciones con SSO que dificultan su implementación, por ejemplo, ¿cómo se maneja cuando un usuario hace clic en "Cerrar sesión" en uno de los sitios? ¿Los desconectas de todos? ¿Si es así, cómo?

Si desea hacer SSO a la derecha, debe considerar usar una solución de SSO, como Shibboleth (FOSS) o Atlassian Crowd (Solución comercial a un precio razonable).

Si no tiene los recursos para utilizar un producto SSO como los anteriores, terminará pirateando las restricciones de seguridad actuales que hacen que el SSO sea tan difícil.

Answer 2

Use el alcance del servidor. Se comparte entre las aplicaciones.

http://help.adobe.com/en_US/ColdFusion/9.0/Developing/WSc3ff6d0ea77859461172e0811cbec0c35c-7fdb.html

Answer 3

Publicar esto como la respuesta dada nueva información.

Advertencia

Asegúrese de que todas las aplicaciones tengan: a) nombres de ámbito de aplicación únicos para variables persistentes, o b) todas las variables de ámbito de aplicación para el mismo fin tengan el mismo nombre.

Muy bien, con eso fuera del camino, si todas sus aplicaciones están en un solo dominio en subcarpetas, cambie this.name name o el atributo de name de cfapplication la misma manera, y todas las aplicaciones compartirán la misma session y application variables de alcance de la application . Esto asegurará que si usa session.loggedin en una aplicación, esa misma variable session.loggedin estará disponible para todas las aplicaciones con el mismo nombre debajo de ese dominio.

Solo tiene que probar cuidadosamente para asegurarse de no terminar usando Application.LoginService en Portal para su LoginService.cfc , y Application.LoginService en Atlas para un LoginService.cfc diferente, o un propósito completamente diferente.

Answer 4

Estás muy cerca de la solución variable del cliente.

Configure una base de datos remota con la que puedan hablar todas las aplicaciones, ya sea a través del DSN, o a través de otro punto de entrada único (es decir, un servicio web).

Decide una forma común de identificar usuarios en todas tus aplicaciones (es decir, crea tu propio sessionid único, quizás basado en CFID / CFTOKEN, CreateUUID (), o cualquier otra cosa que puedas garantizar es único).

Cree su proceso de autenticación para que cuando alguien se autentique en alguna parte de la granja de aplicaciones ... en cualquier lugar ... ese sessionid único se almacene en la base de datos remota.

Pase ese sessionid único de la aplicación a la aplicación. Tal vez lo añada a sus hipervínculos o lo almacene en las variables del cliente (cookies) que mencionó anteriormente.

Finalmente, en su lógica de aplicación que verifica si alguien está autenticado, antes de forzarlos a iniciar sesión de nuevo ... use sus variables de cliente (o el sessionid único pasado) para verificar con el origen de datos remoto, y auth si ha encontrado / verificado.

Esta es una simplificación excesiva, pero es la base para el inicio de sesión único, y debe hacer que piense en la dirección correcta.

PD: mantenga todas sus aplicaciones en el mismo dominio, si es posible (xx.mysite.com, yy.mysite.com) para que las variables de cliente (cookies) se puedan configurar para que sean específicas del dominio, lo que les permite atravesar la granja de aplicaciones. como lo necesites.