Estoy trabajando en una API para un servicio REST que voy a producir y consumir. Pasé los últimos días tratando de descubrir cómo manejar la autenticación de manera agradable, y creo que finalmente se me ocurrió algo.
Se me ocurre esto en base a los siguientes hechos sobre la pila de aplicaciones:
- Cliente y servidor están en .NET4 (parte del cliente en el perfil del cliente)
- El servidor expone utilizando WCF REST
- Realmente no quiero guardar el nombre de usuario y la contraseña en la memoria de la aplicación
A partir del 3, quería usar una forma de autenticación de token, para que después de que el servidor verifique las credenciales, el cliente recupere un token para usarlo en el resto de la aplicación (esto me permitirá hacer otras cosas, como agota el tiempo de espera de los usuarios, pudiendo moverlos sin problemas entre las versiones web y de escritorio, etc. Después de descubrir cómo hacer que las llamadas se reproduzcan y sean resistentes a manipulaciones, se me ocurrió lo siguiente:
- Antes de que el cliente intente autenticarse, genera un par de claves Diffie-Hellman usando la
ECDiffieHellmanCngclase. - Envía la parte pública del par de claves a través del cable junto con el nombre de usuario y la contraseña (sobre HTTPS, por supuesto).
- El servidor autentica la combinación de nombre de usuario / contraseña, si tiene éxito, luego hace lo siguiente:
- Crea un token de sesión único
- Genera su propio par de claves DH y calcula el secreto compartido a partir de la clave pública proporcionada por el cliente
- Toma nota del token de sesión, el secreto compartido, el usuario y el tiempo de "última acción" (utilizado para una ventana de vencimiento continua) en su base de datos
- Devuelve el token de sesión, su clave DH pública y un mensaje de autenticación correcta
- El cliente toma la clave DH de la respuesta, calcula el secreto compartido y almacena el token y el secreto en la memoria.
A partir de este momento, la combinación de token / secreto de sesión funciona como la mayoría de las otras API REST, con la solicitud de huellas digitales y marca de tiempo, y luego se genera algún tipo de HMAC. Cada vez que un cliente realiza una acción contra el servidor, comprueba el par token / secreto, y permite la acción si es válida y no ha caducado, y actualiza el último registro de acción en la sesión.
No veo ningún defecto obvio, y probablemente esté sobre diseñado para esto, pero necesito aprender cómo hacerlo en algún momento. El HMAC evita los ataques de repetición, la negociación de DH ayuda a prevenir los ataques de MITM (no puedo pensar en un ataque viable desde la parte superior de mi cabeza entre HMAC / DH).
¿Algún agujero que alguien pueda hacer en esto?
fuente
Respuestas:
En lugar de inventar el suyo, debería considerar leer la API de OpenAM y tomarla prestada.
http://forgerock.com/openam.html
OpenAM Wiki es particularmente útil
https://wikis.forgerock.org/confluence/display/openam/Home
No necesita usar sus componentes. Pero si usa su API, encontrará que su vida será más simple a largo plazo.
fuente
Estoy 100% de acuerdo con @ S.Lott en que no quieres rodar el tuyo. Sugiero buscar otra alternativa: el Servicio de control de acceso (ACS) de Windows Azure. ACS cuesta dinero, pero es muy barato (10,000 transacciones por $ 0.01) y se maneja una buena cantidad de infraestructura. WIF se apalanca en el cliente.
Esta también es una solución basada en estándares / reclamos, que está de moda. Consulte este artículo sobre el uso de WCF y REST y ACS juntos .
Si está pensando en el futuro, este también es un mecanismo que puede crecer con usted, ya que tiene aplicaciones móviles fuera del firewall, socios, etc. Incluso si no desea utilizarlo, ya que agrega una dependencia fuera de su firewall, puede consultarlo para obtener ideas. Muy hábil.
¡Buena suerte! -Cuenta
fuente