|
|
| Línea 8: |
Línea 8: |
| | ==Definición de los componentes == | | ==Definición de los componentes == |
| | Existen dos componentes que son vitales para el funcionamiento de la plataforma. | | Existen dos componentes que son vitales para el funcionamiento de la plataforma. |
| − | *Arai-Registry: Repositorio central de servicios y aplicaciones | + | *[[SIU-Arai/registry|Arai-Registry]] |
| | *Arai-Usuarios: Proveedor y Administrador de Identidad (término del [[wikipedia:Identity_provider|IdP]] e [[wikipedia:Identity_management_system|IdM]]) para toda la plataforma. Destaca la provisión del servicio de ingreso único ([https://es.wikipedia.org/wiki/Single_Sign-On Single Sign On]) | | *Arai-Usuarios: Proveedor y Administrador de Identidad (término del [[wikipedia:Identity_provider|IdP]] e [[wikipedia:Identity_management_system|IdM]]) para toda la plataforma. Destaca la provisión del servicio de ingreso único ([https://es.wikipedia.org/wiki/Single_Sign-On Single Sign On]) |
| | | | |
| Línea 18: |
Línea 18: |
| | | | |
| | ==Configuración de dependencias y Servicios == | | ==Configuración de dependencias y Servicios == |
| − | La plataforma cuenta con ARAI-Registry como un componente dedicado al manejo del catálogo de dependencias y servicios, así como su configuración. Tomemos como ejemplo la comunicación entre dos módulos, X e Y. Para que esto suceda, se tiene que resolver una serie de requerimientos como ser la autenticación, la ruta de acceso, entre otros. Se establece que el '''Módulo Y''' ya se encuentra registrado previamente a la plataforma.
| + | |
| − | | + | TODO: libsodium |
| − | [[Archivo:Registry-figura-1.png|no|miniaturadeimagen|612x612px]]
| |
| − | | |
| − | Para lograr esta tarea, por medio de la librería arai-cli cada sistema desarrollado por el SIU cuenta con una serie de comandos de consola que permiten registrar un módulo a la plataforma SIU-Araí. El primero es '''registry:add''' y lo que realiza es el registro del módulo en el catálogo de servicios de ARAI-Registry. Al registrar, el módulo indica si se trata de:
| |
| − | * una aplicación
| |
| − | * si provee o consume un servicio (como de SSO),
| |
| − | * si provee y/o consume una API tipo rest
| |
| − | En los casos que sea necesario, el módulo indica también su punto de acceso (conocido como endpoint), así como las credenciales que posee o con las cuales desea consumir algo. <blockquote>Nota: el comando '''registry:add''' sólo se ejecuta la primera vez. Luego se utiliza un comando distinto para mantener sincronizado los datos.</blockquote>
| |
| − | [[Archivo:Registry-figura-2.png|no|miniaturadeimagen|732x732px]]
| |
| − | | |
| − | Una vez ''registrado'' el módulo, se procede a su sincronización con el catálogo de servicios en ARAI-Registry. Para ello se ejecuta otro comando, '''registry:sync''', que se encarga de tomar las definiciones del módulo y procesarlas (si ofrece servicios, informarle sobre posibles consumidores; si los consume, informarle de los puntos de acceso y mecanismos de autenticación, etc). <blockquote>Nota: siempre que los datos de acceso del módulo cambien, se incorporen nuevos proveedores o consumidores, se ha de ejecutar la sincronización para actualizar los datos. ARAI-Registry ''de ninguna forma enviará esta información'' de manera pro-activa, como en el caso del ejemplo para informar al '''Módulo Y'''.</blockquote>[[Archivo:Registry-figura-3.png|no|miniaturadeimagen|732x732px]]
| |
| − | | |
| − | A partir de este punto el '''Módulo X''' es capaz de conectarse de forma directa al '''Módulo Y''' para consumir sus recursos (por ej, una API rest). En tal caso, las credenciales del cliente serán conocidas para el servidor, lo que validará el intento de acceso a dicho recurso.<blockquote>Nota: este ejemplo supone que '''Módulo Y''' ya se registró al catálogo de servicios de ARAI-Registry como proveedor de una API rest. También supone que se ejecutó una sincronización en '''Módulo Y''' luego de haberse sincronizado el '''Módulo X'''.</blockquote>
| |
| − | [[Archivo:Registry-figura-4.png|no|miniaturadeimagen|602x602px]]
| |
| − | | |
| − | El catálogo de servicios ARAI-Registry, como se explicó hasta ahora, no se entromete en la comunicación directa entre los módulos de la plataforma. Simplemente brinda un mecanismo de descubrimiento y configuración de servicios. Toda la comunicación posterior entre módulos, pasa de forma desapercibida para el resto la plataforma.
| |
| | | | |
| | [[SIU-Arai|< Volver]] | | [[SIU-Arai|< Volver]] |
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 dos componentes que son vitales para el funcionamiento de la plataforma.
- Arai-Registry
- 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)
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).
Configuración de dependencias y Servicios
TODO: libsodium
< Volver
