¿Es una mala idea usar tokens de portador de SAML para autenticar usuarios a servicios de backend?

Question

Supongamos que tengo una aplicación de interfaz que quiere obtener algunos datos de un servicio de fondo. (Sí). El servicio deberá verificar que el usuario final esté autenticado, que esté autorizado para usar el servicio y posiblemente filtre los datos devueltos en función de los privilegios del usuario. En mi caso, tanto la aplicación de front-end como el back-end se basan en Azure ACS para la autenticación.

Idealmente el front-end le gustaría actuar en nombre de el usuario autenticado, que suena como un buen ajuste para el uso de un token de ActAs (como se especifica en WS-Trust). Sin embargo, resulta que ACS does not currently support ActAs.

Una solución podría ser utilizar el token de token real (el token de arranque en la aplicación de front-end) para autenticarse en el servicio de fondo. It's not hard to do, pero sería una mala idea por alguna razón?

Answer 1

Desde su aplicación de front-end, puede transferir los datos de identidad del usuario final enviando el token tal cual o enviando los atributos desde él. Ambos tienen problemas. Para el primero, si también está encriptado, los front-end y back-ends tendrán que compartir la clave privada necesaria para descifrarlo; también deberán compartir restricciones de audiencia, etc. para que el back-end considere el token válido para él. En otras palabras, las partes frontales y posteriores serán UNA parte dependiente, no dos. Puede que no sea un problema, pero ten en cuenta. En este último caso, terminas enviando datos de usuario de forma propietaria, lo que podría aumentar los costos de integración y mantenimiento a lo largo del tiempo. En ambos casos, puede autenticar la aplicación de front-end al back-end utilizando algún otro tipo de credencial, por ejemplo, un certificado utilizado en el nivel de transporte y, por lo tanto, formar un subsistema de confianza entre ellos.

Una cosa que sugiero que consideres es OAuth 2. A partir del this blog post, me parece que ACS lo admite (aunque no tengo ninguna experiencia de primera mano). Lo verdaderamente maravilloso de OAuth 2 es que integra la delegación, y NO ES DONDE ES tan complejo como ActAs en WS-Trust. El resultado neto es el mismo, es decir, el servicio de fondo tendrá información sobre el servicio de llamadas y el usuario final, pero la cantidad de esfuerzo para lograrlo es incomparable. Los tokens seguirán siendo tokens de portador, pero puedes mitigarlo hasta cierto punto usando SSL. Más allá de SSL, puede implementar algunas medidas adicionales, pero la mejor, IMO, sería si Microsoft hiciera algo en ACS como lo hizo Google con sus tokens de acceso para cuentas de servicio que usan claves asimétricas que están encadenadas a una PKI. (Por lo que sé, Microsoft ya puede haber hecho algo así; si es así, está configurado.)

De todos modos, HTH!