Brokered Authentication

Además, aun cuando Direct Authentication se aplica con éxito, si un consumidor determinado requiere acceso a numerosos servicios como parte de la misma actividad de servicio en tiempo de ejecución, se le puede pedir que proporcione credenciales separadas para cada servicio. En este caso, el consumidor puede necesitar almacenar en caché las credenciales para su uso con actividades adicionales en tiempo de ejecución, que puede resultar en que el consumidor tenga que almacenar una contraseña temporal, que genera amenazas de seguridad adicionales.

 Un agente de autenticación se añade como una extensión arquitectónica capaz de evaluar las credenciales de los consumidores, sin la necesidad que los consumidores tengan relaciones directas con los servicios a los que necesitan acceder. Tanto los consumidores como los servicios confían en el agente de autenticación, lo que permite que se convierta en un mecanismo de autenticación centralizada y emisora de credenciales dentro del inventario general de la arquitectura.
 Este patrón se aplica generalmente en el despliegue de un producto intermediario en la autenticación o de la plataforma. Las arquitecturas internas de estos productos pueden variar en como llevan cabo las funciones de los agentes. Los agentes de autenticación son capaces de emitir señales a los consumidores, para futuras interacciones. Por ejemplo, si la solicitud del consumidor es el acceso a un servicio específico, el agente puede emitir un token para un consumidor, autorizándolo específicamente para ese servicio, permitiendo a los consumidores interactuar en varias ocasiones con el servicio utilizando el mismo acceso emitido por el agente.
Hay una gran variedad de tecnologías de seguridad asociadas con los agentes de autenticación:
• La infraestructura PKI X.509 utiliza una entidad emisora de certificados para la firma y la emisión de certificados X.509.
• El protocolo Kerberos, que utiliza un servicio de autenticación y un servicio de concesión de tickets para la emisión de tickets.
• La especificación WS-Trust, describe un protocolo utilizado por Security Token Services (STS) para la emisión de tokens como SAML y SECPAL
Los tokens de seguridad pueden contener datos sensibles y por lo tanto deben ser protegidos en tránsito a través de Data Confidentiality o el uso de un título de transporte de capa, como SSL. Estos tokens deben ser firmados por el agente. Si no lo están, su integridad no puede ser verificada, lo que podría resultar en atacantes tratando de emitir falsos tokens.
En otras palabras, un corredor puede emitir tokens de seguridad que se utilizan a través de fronteras organizativas y los dominios de seguridad autónomas, cada una de las cuales puede tener su propio corredor.

 Ventajas
 \* Se crea una capa de validación de ingreso de tal forma que se genere un token y el acceso a los servicios sea más seguro.
\* Validación sin la necesidad de que los consumidores tengan relación directa con los servicios a los cuales necesitan acceder
\* Simplifica el desarrollo de los servicios individuales
\* Puede reducir aún más la carga de gobierno asociada a la gestión de identidades
\* En caso de que un agente de dicha autenticación de estar disponible en cualquier momento, podría paralizar la comunicación de servicio. (Podría mitigarse algo usando Redundant Implementation)