Autenticación centralizada y autorización para varios servicios web

Question

Existen varios servicios web distintos, varias tecnologías utilizadas, como Java, .NET, Python, Perl y posiblemente más en el futuro, que pertenecen a diferentes organizaciones y el acceso a esos servicios web tiene que ser restringido.

La idea es tener un servidor central de autenticación y autorización, solo responsable de otorgar acceso a cada WS.

Estoy buscando un sistema de inicio de sesión único en el que el usuario se autentica una vez con el servidor de autenticación y se le concede acceso a los servicios web durante un tiempo limitado.

Los requisitos de seguridad son altos, por lo que un conjunto de nombre de usuario/contraseña no es suficiente.

En una búsqueda rápida encontré muchas soluciones diferentes y enfoques para el problema, pero no sé cuál es la mejor para este caso: una solución independiente, segura y confiable de tecnología.

Answer 1

¿No es exactamente para lo que es OpenID?

Por favor, corríjanme si me equivoco.

Answer 2

Hicimos una gran investigación sobre el tema y tampoco pudimos encontrar una solución adecuada. (Una solución casi buena, pero no tanto para webservices es http://www.atlassian.com/software/crowd/)

Desarrollamos también un sistema de administración de usuarios sso y central para nuestras aplicaciones WS (también aplicaciones de terceros) pero no está a la venta.

Si prueba soluciones, debe verificar el rendimiento de los sistemas, especialmente bajo carga. Al principio, nuestros sistemas eran 30 veces más lentos. Normalmente encontrará la ralentización en el análisis xml y el número de solicitudes que tiene que hacer (normalmente donde tenía una solicitud en el futuro, tendrá al menos 4). (Usamos jmeter para probarlo). Y debe configurar los sistemas de conmutación por error, porque creará un solo punto de falla con sso.

Answer 3

Este problema ha sido resuelto en gran medida por WS-Trust, al menos para los servicios web basados ​​en SOAP. WS-Trust es un protocolo bien definido para validar e intercambiar "tokens de autenticación", y se puede usar en escenarios entre empresas con protocolos como WS-Federation basados ​​en él.

Un caso de ejemplo es hacer que los clientes soliciten un token del servidor WS-Trust, luego incluir ese token en el encabezado SOAP en el host del servicio web. La otra cara es incluir algo simple como <UsernameToken> en la solicitud al host, y tener la autenticación delegada del lado del servidor al servidor WS-Trust.

WS-Trust tiene una buena compatibilidad con el cliente: WCF tiene soporte inmediato y varios proveedores tienen interceptores J2EE para servicios web JAX-RPC y JAX-WS.

Si bien el objetivo de WS-Trust es la autenticación, puede hacer una autorización de grano grueso mediante el uso de la lógica sobre cuándo emitir o validar un token recibido. No publique/valide el token, y el acceso es denegado efectivamente. La autorización detallada para servicios web generalmente requerirá algunos interceptores personalizados, que son específicos del proveedor.

Trabajo para IBM Tivoli Security, y tenemos algunos productos en este espacio. El primero es Tivoli Federated Identity Manager (TFIM). Un colega y yo escribimos this article sobre la integración de TFIM con servicios web basados ​​en WSE, e incluye una descripción general del protocolo WS-Trust.El segundo producto es Tivoli Security Policy Manager (TSPM), que implementa una autorización detallada para servicios web.

Existen implementaciones de código abierto de estos mismos protocolos, que es la ventaja de utilizar una solución basada en estándares. Creo que JBoss y WSO tienen implementaciones que pueden ser útiles.