SIU-Arai/Arquitectura
Arquitectura de la plataforma
La siguiente imagen expone el detalle de la arquitectura general de la plataforma, así como la vinculación entre componentes internos, módulos del SIU y aplicaciones o sistemas externos.
Definición de los componentes
Existen tres componentes que son vitales para el funcionamiento de la plataforma.
- Arai-Registry: Registro de aplicaciones y servicios
- Arai-Usuarios: Proveedor y Administrador de Identidad (término del IdP e IdM) para toda la plataforma. Destaca la provisión del servicio de ingreso único (Single Sign On)
- Arai-Cli: Librería de cliente de la plataforma, que provee de servicios de bajo nivel facilitando la integración de los componentes
A partir de allí, es posible encontrarse con otros módulos que la complementan.
- SIU-Huarpe: es el portal de la plataforma, punto de acceso único para los usuarios y concentrador de diversos servicios ofrecidos
- SIU-XXX: toda aplicación del SIU capaz de ser integrada a la plataforma, conocido aquí como módulo.
También pueden ir apareciendo en escena futuros módulos o componentes que ofrezcan servicios puntuales. La plataforma es totalmente flexible en este punto. En todos los casos, los servicios ofrecidos han de implementar protocolos de comunicación basados en el estándar REST. Esto es lo que permite lograr el despliegue de una arquitectura basada en servicios (Service Oriented Architecture).
Despliegue de la plataforma
La plataforma posee diversos componentes que se deben resguardar y/o facilitar su acceso dependiendo del público objetivo. No tener en cuenta esto puede comprometer la integridad de todos los componentes, módulos y servicios involucrados.
El esquema de despliegue recomendado para la plataforma es el que muestra en la siguiente figura
En el proceso de despliegue de los componentes y servicios, se han de tener en consideración los siguientes factores:
- El portal SIU-Huarpe es de acceso público, lo pueden utilizar los usuarios desde cualquier origen (se recomienda brindar el acceso desde internet sin restricciones)
- El portal SIU-Huarpe puede requerir el acceso de las API de los módulos registrados en la plataforma, pero dichas API no deben en principio estar disponibles desde mas allá del portal
- El IdP (componente parte de SIU-Araí: Usuarios) es el que provee el formulario de autenticación, por lo tanto debe ser de acceso público (con FQDN propio)
- Tanto el IdM (parte de SIU-Araí: Usuarios) como los módulos SIU-XXX deben ser accesibles desde la red interna de la institución, pero no de forma pública
- El componente SIU-Araí: Registry es un componente exclusivo para sincronización de la plataforma y NO DEBE ser expuesto a conexiones fuera de la red de aplicaciones y módulos
Seguridad de la plataforma
SIU-Araí es concebida como un conjunto de componentes, que trabajando de forma mancomunada, conforman el camino hacia una Arquitectura Orientada a Servicios o SOA. Bajo este esquema, los servicios deben ser de bajo acoplamiento, autónomos, reusables, homogéneos, etc. Para lograr estos y otros factores, SIU-Araí establece ciertas pautas o mecanismos de trabajo:
- Protección en descubirimiento y configuración de servicios mediante encriptación de datos
- Protección en la transmisión de los datos mediante encriptación con el uso obligado de HTTPS
- Protección en la autenticación con el intercambio entre el IdP y un SP mediante encriptación de token
Descubrimiento y configuración de servicios
En la plataforma SIU-Araí, el componente Registry es el responsable de mantener la información de que servicios son ofrecidos y por quienes son consumidos. Esto
Claves de encriptación basadas en libsodim, para encriptar datos de acceso intercambiados en el descubrimiento y publicación de servicios
Transmisión de los datos encriptados
Para que sea posible garantizar que la transmisión de datos entre todos los componentes de la plataforma sea seguro, mínimamente se ha de implementar el protocolo HTTPS.
Autenticación
Para garantizar que aplicaciones de terceros no hagan un uso irrestricto del mecanismo de autenticación basado en el protocolo SAML, el componente Identity Provider o IdP de la plataforma requiere que se lo configure con un juego de certificados público/privado. Estos operan de la siguiente manera:
- Al instalar el IdP, se le debe configurar el par de certificados público/privado
- Al registrar el IdP a la plataforma, Registry aprende cual es el certificado público y lo guarda en el catálogo
- Al registrar un SP a la plataforma, Registry informa al cliente el certificado público del IdP. Así aprende como comunicarse de forma segura el SP con el IdP
- El SP inicia un intercambio con el IdP, en la negociación se encripta los datos y lo recibe el IdP solamente si puede desencriptar dichos datos
Este mecanismo de intercambio previo de la clave sumado a la validación posterior, garantizan el uso del IdP por parte de módulos o SP autorizados únicamente.
