session - tag - verificar codigo analytics

¿Cómo crear un Servicio de inicio de sesión compartido en múltiples dominios?

Question

Estoy interesado en cómo implementar un sistema de inicio de sesión compartido entre dominios, así como las mejores prácticas y precauciones de seguridad. Si está familiarizado con 37Signals, probablemente esté acostumbrado a su uso de tener un mecanismo de autenticación universal compartido por el cual no tiene que iniciar sesión posteriormente si usa el nivel superior de navegación para un producto diferente. Me gustaría implementar algo de manera similar.

Lo más parecido que he encontrado en línea es la entrada de Wikipedia en un Servicio de Autenticación Central y la respuesta al Inicio de sesión de dominios cruzados: cómo iniciar sesión automáticamente cuando se transfiere de un dominio a otro , lo que puede ser ligeramente diferente en este caso.

He inspeccionado sus cookies de sesión para comprender lo que están haciendo en el proceso. Inicialmente, cada enlace de producto tiene un uristub "goto", es decir:

https://MY_COMPANY.campfirenow.com/id/users/[int_identifier]/goto

Usando FireCookie y la pestaña NET en Firebug, puedo ver las cookies que se configuran y los redireccionamientos que ocurren en el proceso. La url goto dispara una redirección 302 a:

https://MY_COMPANY.basecamphq.com/login/authenticate?sig=[BASE64_ENCODED_AND_ENCRYPTED_DATA]

El identificador de sesión se recrea, muy probablemente para fines de CSRF. Algunos de los datos en las cookies, así como el parámetro GET sig, se descifraron parcialmente utilizando base64_decode para lo siguiente:

// sig GET param
array(2) {
  [0]=>
���ף�:@marshal_with_utc_coercionT7�z��<k��kW"
  [1]=>
  string(18) "���k�<kn8�f���to��"
}

// _basecamp_session cookie session param
string(247) {
:_csrf_token"1Sj5D6jCwJKIxkZ6oroy7o/mYUqr4R5Ca34cOPNigqkw=:session_id"%060c0804a5d06dafd1c5b3349815d863"
flashIC:''ActionController::Flash::FlashHash{:
@used{: auth{"
              MY_COMPANY{:
                       user_idi�3
:identity_idi�W����������s�]��:�N[��:

߾ "

La codificación está rompiendo el bloque de código. ¡Gracias por tu ayuda!

Answer 1

¿Has probado algo como Charles para olfatear lo que se envía de ida y vuelta? Puede ser capaz de analizar las cosas más por ti.

Como lo menciona FlipScript , ¿quizás usar OAuth / OpenID podría ser una forma de avanzar para usted?

Answer 2

Creo que la clave de tu Q es donde escribes "por lo que no tienes que iniciar sesión posteriormente si utilizas la navegación de nivel superior para un producto diferente".

Explicaré lo siguiente: Desea poder cambiarse de site1.com a site2.com y dejar que site2.com sepa que usted es un usuario que inició sesión en site1.com.

Debido a que las cookies no se pueden compartir entre dominios diferentes (distintos de los subdominios pero supongo que no están hablando de subdominios), debe pasar cierta información en el enlace a site2.com que le permitirá hablar con su back-end y saber qué usuario que eres

Comencemos con una solución ingenua y luego trabajemos para resolver algunos de los problemas que plantea: supongamos que tiene una tabla de usuarios en algún DB back-end y su usuario tiene alguna ID. ahora asuma que el usuario se autenticó en site1.com y que él es el usuario 123 de su base de datos. La solución más ingenua sería llamar a site2.com/url/whatever?myRealID=123 y hacer que Site2 verifique esta identificación y "creer" que el usuario es él.

Problema: Cualquier persona (incluso un usuario válido de su sitio) que verá su enlace puede crear un enlace con myRealID = 123 o intentar con otros valores. y site2.com lo aceptará como ese usuario.

Solución: no use ID adivinables suponga que agrega a su tabla de usuarios un GUID único y si el usuario 123 tiene una guía de 8dc70780-15e5-11e0-ac64-0800200c9a66, llame a site2.com/url/whatever?myGuid=8dc70780-15e5- 11e0-ac64-0800200c9a66.

Nuevo problema: bueno, aunque sería muy poco probable que alguien adivine el GUID de su usuario, su GUID aún puede ser secuestrado por un intermediario que ve este enlace y alguien tendrá la guía para poder usarlo para siempre.

Solución: utilice una clave privada guardada en su servidor para firmar una cadena que contenga los siguientes elementos de datos, marca de tiempo actual, sitio de destino (es decir, "sitio2.com") dicho GUID, esta firma se puede traducir para decir "Esto es una prueba de que este enlace fue creado por el sitio en ese momento para el usuario que tiene este GUID autenticado por este dominio "y lo envía a site2.com junto con la marca de tiempo y el GUID. Ahora cuando site2.com obtiene el enlace, puede asegurarse de que esté firmado correctamente y si algún intermediario o usuario original intentara cambiarlo de alguna manera (ya sea modificando la hora o el GUID), entonces la firma no coincidiría con el sitio2. com se negará a autenticar al usuario.

Un último problema: si el intermediario intercepta el enlace, puede usarlo si lo hace desde otra máquina.

Solución: agregue un nonce a los parámetros pasados. El nonce es solo un número aleatorio que su sistema de autenticación debería asegurarse de que no le permite autenticarse con este número más de una vez (de ahí entonces nombre N (umber) -ONCE). Tenga en cuenta que esto significa que cada enlace que cree en site1.com que conduzca a site2.com debe tener un nonce distinto que debe guardarse en el back-end para su posterior validación.

porque no desea seguir agregando registros a esta tabla nonce para siempre, es costumbre decidir que dicho enlace solo es válido por algún tiempo dado después de su creación. y entonces usted puede crear registros nonce que son más antiguos que este límite de tiempo.

Espero que este sea el bosquejo que estabas buscando. Es posible que me haya perdido algo, pero esas son las pautas básicas, use una firma para probar la autenticidad de los datos en el enlace y use un código para evitar los ataques de los intermediarios. También recomendaría usar HTTPS para esos enlaces si es posible.

Eyal

Answer 3

Eche un vistazo a Jasig CAS http://www.jasig.org/cas . Creo que hará lo que quieras. Es de código abierto, y tiene una serie de complementos que le permiten autenticarse. Utilice múltiples fuentes de autenticación y desde múltiples dominios / idiomas.

Answer 4

Permitir a los usuarios la opción de usar su solución facebook / yahoo / gmail / openID es un comienzo, pero eso no soluciona definitivamente la solución de implementar o usar la propia solución.

Habiendo desarrollado y administrado una implementación en el pasado (finalmente nos dirigimos a SiteMinder, pero supongo que no desea el costo de un producto real), creo que Eyal tiene una muy buena idea, pero agregaría un poco ajuste a eso.

En el momento de la autenticación, genere un código aleatorio (podría ser un valor GUID, pero no es estático por usuario) que se almacena en una tabla transaccional junto con la identificación del usuario. Este código tiene una duración máxima (deberá juzgar el valor de seguridad para ese período de tiempo). Idealmente, este código debe ser hash con el nombre de usuario o encriptado y enviado como parte de la URL.

Answer 5

Podría intentar implementar una solución de inicio de sesión automático de red global a la desbordamiento de la pila.
Hay una publicación interesante sobre su brillante implementación por Kevin Montrose here .

Requeriría Cookies, HTML5 localStorage , Javascript, Iframe y muchos controles de seguridad, pero creo que vale la pena.

Answer 6

Por qué no utilizar Open ID para este propósito.

OperID será la solución óptima para este problema.

Answer 7

Use algo como .NET Passport (IE, Windows Live Id) o la forma en que Facebook lo ha hecho con su API, que se puede ver abiertamente.