Cuál es la mejor manera de tener Autenticación para un servicio web

Question

Tenemos una API de servicio web .NET. Actualmente, las personas usan la definición de SOAP para consumir la API, porque necesitamos autenticación a través de un elemento de Autenticación personalizado en el encabezado SOAP. Funciona perfectamente. multa.

SOAP requiere que la solicitud sea POST. Queremos permitir a los usuarios usar un verbo GET (para que pueda ser almacenado).

Entonces, ¿cuál es la mejor manera de ofrecer una API GET simple (no tiene que ser un servicio web) que también ofrece autenticación?

Ejemplo de API de rutas:

http://www.blah.com/api/Search?query=Foo

¿Es esta una práctica aceptable y común?

http://www.blah.com/api/Search?query=Foo&Key=<some guid>

NOTA: También no quiero implementar SSL ni instalar software o plugins extra en IIS, etc, etc

Answer 1

Si el servicio web necesita ser asegurado, y asumo que sí, ya que actualmente tiene un encabezado Autenticación, entonces debería reconsiderar el uso de GET y no usar SSL, al menos para la pieza de autenticación. Como mínimo, PUBLICARÍA la solicitud de autorización a través de SSL al servicio/aplicación web. Si no desea proporcionar autenticación en cada solicitud, deberá aceptar (y generar en el servicio) una cookie de autorización que el consumidor puede usar para solicitudes posteriores.

Evitaría usar la autenticación en la URL exactamente por el motivo por el que desea admitir GET: si la URL se puede almacenar en caché, las credenciales también se almacenarán en caché. Esto rompe la seguridad del servicio web ya que cualquiera puede reutilizar las credenciales en caché.

Answer 2

Usando una API solo GET, tendré un primer método que obtenga una ID de sesión única.

como son: GET/api action = auth & nombre de usuario = usuario & password = hashedpassword devolvería un 16 chars token, que se almacenan en su lado y que requieren este token único para cada llamada posterior.

Si la API se realizó en PHP, puede utilizar su funcionalidad de manejo de sesión de PHP para lograr esto (tiene tiempo de espera/recolección de basura). Hay funciones similares en ASP.NET.

Es vulnerable al ataque de reproducción (alguien agarrando o adivinando el ID de la sesión), pero si quiere algo simple, ese es el camino a seguir. Cualquier sitio web que no sea HTTPS sería vulnerable de la misma manera. Puede vincular la ID de la sesión con la dirección IP del usuario para mayor seguridad.

Answer 3

Si está utilizando WCF puede construir en los mecanismos de seguridad incorporados. Si no quiere utilizar marcos estándar para la seguridad, lo más probable es que vaya a hacer la seguridad por oscuridad.

Answer 4

Si sus clientes están en el mismo dominio, puede activar la autenticación integrada de Windows en su aplicación IIS. Su aplicación ahora solo aceptará usuarios autenticados de Windows. Agregue su propio RoleProvider para una granularidad más precisa basada en roles.

Answer 5

Similar a la respuesta de Thomas Eyde: puede usar un sistema de inicio de sesión único como SiteMinder para asegurar la URL. La persona que llama solicita la necesidad de incluir un token, que generalmente se almacena en una cookie, pero se puede agregar a la cadena de consulta.

Cualquier SSO o plataforma de administración de servicios web intencionalmente dificultará la autenticación si no se usa SSL.