Parte 1: Seguridad federada y gestión de identidades

En un modelo tradicional de implementación de sistemas locales, las aplicaciones cliente y los servicios residen en la misma LAN o en varias LAN interconectadas y se comunican entre sí mediante credenciales de dominio (o de confianza). Una vez que se separen entre los servicios y los clientes, se debe proporcionar una forma unificada para que los clientes se autentiquen y usen los servicios fuera de los límites de su dominio. Aquí es donde la seguridad federada es útil.

Definición de Seguridad Federada, desde MSDN en inglés:

«La seguridad federada permite una separación clara entre el servicio al que accede un cliente y los procedimientos de autenticación y autorización asociados. La seguridad federada también permite la colaboración entre múltiples sistemas, redes y organizaciones en diferentes ámbitos de confianza».

La administración de identidades federadas es responsable de autenticar las credenciales de usuario y proporcionar tokens de acceso para acceder a los recursos en la plataforma C-Insight. Las identidades son administradas por un sistema de terceros y creadas por nuestro equipo de operaciones en función del alcance del proyecto. Los usuarios usan esas credenciales para interactuar con la plataforma C-Insight utilizando aplicaciones móviles, web y de escritorio. El componente responsable de autenticar las credenciales de usuario y proporcionar tokens se llama servidor de autorización y es independiente del proveedor de la nube para eliminar el bloqueo del proveedor. En el siguiente diagrama se muestra el flujo de inicio de sesión del usuario:

1. Las aplicaciones cliente envían credenciales solicitando un token de acceso.
2. El servidor de autorización valida las credenciales en el sistema de gestión de identidades y accesos (IAM, por sus siglas en inglés).
3. Una vez autenticado, el token de acceso se emite con las notificaciones de usuario y se devuelve a la aplicación cliente.
4. El cliente solicita un recurso a la puerta de enlace API con el token emitido.
5. La puerta de enlace API valida las reclamaciones presentadas y reenvía las llamadas a los servicios troncales.

Además de validar las credenciales de usuario en el sistema IAM, el servidor de autorización agrega un conjunto de notificaciones utilizadas por la puerta de enlace API para conceder o denegar el acceso a los recursos solicitados por el usuario. El conjunto de permisos de autorización está totalmente administrado por la plataforma C-Insight en el paradigma RBAC (Control de acceso basado en roles) y no depende de IAM de terceros. Este era un requisito esencial para admitir permisos de adición/actualización/eliminación para roles y permisos de visualización/operación para sensores. Cada agencia en el sistema controla sus sensores y los roles definidos para la agencia proporcionan subvenciones operativas en estos sensores. RBAC es un tema sustancial que se puede cubrir en un artículo propio. La idea principal es que los usuarios asignen roles que son un grupo de permisos. Cada agencia tiene varios roles y un súper rol (administrador de agencia) que configura los permisos para los roles. Cada proyecto tiene un super usuario que crea agencias, roles y asigna usuarios a roles y sensores a agencias.

Los tokens de acceso proporcionados por el servidor de autorización son de corta duración, cifrados y firmados por el certificado X.509. Una vez que se crea el token, no se puede cambiar y para agregar reclamos adicionales se debe crear un nuevo token. También implementamos un detector de actividad maliciosa que invalida todos los tokens emitidos de manera efectiva, lo que obliga a todos los usuarios conectados a volver a iniciar sesión y emitir nuevos tokens. Dado que el token es autónomo, permite la validación sin estado de las notificaciones de usuario y allana el camino para la implementación de múltiples instancias de la puerta de enlace API para admitir un número masivo de usuarios simultáneos.

Otra ventaja de la seguridad federada es la capacidad de exponer la funcionalidad de C-Insight no solo a nuestras aplicaciones cliente, sino también a nuestros socios que utilizan la plataforma en un paradigma B2B. En otras palabras, podemos crear una amplia gama de credenciales de usuario como nombre de usuario / contraseña o nombre de usuario / certificado para diversos requisitos de conectividad.

Al conectarse al servidor de autorización, la aplicación cliente debe presentar un certificado de cliente X.509 de uno de los emisores de certificados de confianza. Una vez que se establece la conexión TLS mutua entre las partes, las credenciales de IAM junto con el ID de cliente y las credenciales de secreto de cliente firmadas y cifradas mediante el certificado de cliente y toda la comunicación de nivel de transporte se cifran mediante un certificado de servidor. Estos 2 niveles de seguridad son vitales para garantizar la integridad y confidencialidad de los mensajes. El siguiente diagrama muestra como funciona TLS mutuo ( https://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication).

 

Estén atentos a la parte 2 de la serie donde vamos a discutir cómo usar la seguridad federada para acceder a la API y suscribirse a las notificaciones.