2011-12-19 13 views
13

Después de crear un servicio REST básico, he llegado al punto en que sería apropiado agregar algún tipo de protección con contraseña, ya que necesito verificar que mis usuarios estén registrados correctamente y que tengan suficientes permisos para ejecutar cualquier acción ellos van a.Contraseña que protege un servicio REST?

El servicio REST principalmente se accede desde una interfaz Javascript-pesado y con eso en mente, he llegado con las dos siguientes alternativas para solucionar esto:

  1. hacer que los usuarios de inicio de sesión credenciales primera envío a una página /login con POST. La página establece una cookie de sesión en la que el usuario es marcado como iniciado sesión, junto con el nivel de permiso. En cada solicitud de siguiente, verifico que el usuario ha iniciado sesión y su nivel de permiso. Cuando la sesión caduque, automáticamente o manualmente (cierre de sesión, el usuario tendrá que volver a iniciar sesión).

  2. Guardar temporalmente las credenciales hash a nivel local y enviar las credenciales de los usuarios a lo largo de cada petición realizada por el usuario para verificar las credenciales & permisos de back-end en una base por-petición.

¿Hay más maneras de resolver esto y hay algo más que me debería preocupar?

+0

Si su back-end está en Java, también podría usar [Apache Shiro] (http://shiro.apache.org/), resolverá muy bien la mayor parte de su problema. – pierpytom

Respuesta

17

Actualmente estoy desarrollando una API REST junto con un cliente (escrito en javascript), a continuación, intentaré explicar los métodos utilizados para proteger la API contra el acceso no autorizado.

  • Haga su API REST para exigen una cabecera de Auth-Key sobre cada solicitud a la API, además de /api/authenticate.

  • /api/authenticate tomarán un nombre de usuario y una contraseña (enviados usando POST), y devolverán la información del usuario junto con el Auth-Key.

  • Este Auth-Key se genera aleatoriamente después de una llamada a /api/authenticate y almacenados en la tabla backend users con la entrada de usuario específico, un hash md5 de la IP remota + el agente de usuario proporcionada por el cliente.

  • en cada petición que el valor de Auth-Key, y la suma md5 mencionado, se busca en users. Si se determina que un usuario válido que ha estado activo durante los últimos minutos N al usuario se le concedió el acceso, si no: http código de retorno 401.

  • En el cliente de REST, primero obtener la Auth-Key mediante la publicación de /api/authenticate, a continuación, almacene este valor en una variable y envíelo en cada solicitud futura.

+0

Gracias por su respuesta. ¿Cómo maneja la expiración de las claves + eventual renovación automática? – Industrial

+0

@Industrial La expiración de las claves es manejada por otro campo llamado 'last_access' en' users'-table, cuando se busca la 'Auth-Key' especificada, también tengo un 'WHERE' claus que dice; 'WHERE last_access> (UNIX_TIMESTAMP() - (N * 60))' –

+0

@Industrial ¿Está buscando una respuesta más elaborada o la publicación actual es suficiente? (Lo estoy preguntando porque no está marcado como aceptado, y si desea puedo proporcionarle más información) –

0

No soy experto en seguridad. Utilizo el marco de trabajo RESTful Play! Y hacen lo siguiente para autenticar a los usuarios.

  1. La cookie está protegida contra manipulación. Está firmado con una clave secreta larga y se verifica para cada solicitud. ¡Solo hash no es suficiente!
  2. Recomiendan establecer información única para identificar al usuario en la cookie. Como el servidor debe ser el único que manipule la cookie, es suficiente.
  3. No ponga la contraseña como credencial en la cookie. Si alguien olfatea la cookie, no solo se puede secuestrar la sesión, sino también la cuenta completa o, incluso peor, otras cuentas con las mismas credenciales.

Si desea proteger la cookie contra el secuestro utilizando https.

1

En primer lugar decidir qué es lo que se está protegiendo contra:

  • autenticación? (¿Quién está solicitando su servicio?)
  • ¿Autorización? (Si una persona determinada puede solicitar correctamente un servicio determinado o no?)

Recomiendo que proporcione claves hash para su servicio. De esta forma, puede administrar el problema clave por separado de los servicios. O una clave de cliente y un secreto, Amazon hace esto.

Siempre es más fácil para el cliente si tiene un protocolo sin estado. Y envíe todo a través de los parámetros, las cookies son una molestia para el cliente también.

Recuerde que es en su interés para que los desarrolladores potenciales utilicen su servicio lo más fácil posible. Un servicio súper seguro que nadie usa es aburrido.

Puede permitir que los clientes elijan el nivel de seguridad dándoles la opción de puntos finales HTTP o SSL/HTTP para conectarse. La elección del cliente es algo bueno.

0
  1. Haga conexión de los usuarios mediante el envío de primera credenciales a una página/login con POST. La página establece una cookie de sesión en la que el usuario está marcado como iniciado sesión, junto con el nivel de permiso. En cada solicitud siguiente , verifico que el usuario ha iniciado sesión y su permiso nivel. Cuando la sesión expire, de forma automática o manual (cierre de sesión, , el usuario deberá volver a iniciar sesión).

  2. Guardar temporalmente las credenciales hash a nivel local y enviar las credenciales de los usuarios a lo largo de cada petición realizada por el usuario para verificar las credenciales & permisos back-end en una base por-petición.

Su primer acercamiento no lo hace la carne del statelessness constraint de descanso. No puede mantener sesiones de cliente en el lado del servidor.Esta restricción hace REST altamente escalable ...

Su segunda solución es apropiada. La forma más simple de usar HTTP basic auth. No es necesario cifrar la contraseña en el lado del cliente. Lo que necesitas es una conexión encriptada. En el lado del servidor puede tener un caché [username, password] -> [identity, permissions], por lo que esta solución es mucho más rápida y superior en todos los sentidos que en las sesiones del lado del servidor.

Por clientes de terceros (no de confianza) la autenticación es más compleja, supongo que no necesita esa parte.

Cuestiones relacionadas