Blog

La versión 1.45.0 del catálogo de componentes web transversal, se ha liberado en los repositorios digitales de medios de la STIC.

Podréis consultarlos desde el Storybook del SAS.

Otros recursos

Recordad que el acceso a los Storybook es a través de la red corporativa del SAS.

Para cualquier duda pueden escribirnos a la Lista de Arquitectura( l-arquitectura.stic.sspa@juntadeandalucia.es ) y trataremos de daros soporte con la mayor brevedad que nos sea posible

 


CHANGELOG

Añadido

  • @sas/stic-icon

    • Añadida la posibilidad de cargar un icono SVG desde una URL.
  • @sas/wc-stic-input-checkbox

    • Añadido el parámetro helperText.

Modificado

  • @sas/wc-stic-badge, @sas/wc-stic-checkbox, @sas/wc-stic-input-checkbox, @sas/wc-stic-filters

    • Modificación visual del componente de acuerdo a la versión 1.5.1 del sistema de diseño.
  • @sas/wc-stic-tag-asistencial

    • Iconos obtenidos a traves de URLs del CDN.
  • @sas/wc-stic-chip-date, @sas/wc-stic-chip-date-range, @sas/wc-stic-chip-text, @sas/wc-stic-chip-select

    • Modificado el comportamiento de las labels cuando un filtro tiene valor.
    • Modificado el icono de eliminar valor.

Deprecado

  • @sas/wc-stic-badge
    • Deprecadas todas las variables CSS.
    • Deprecadas las propiedades info, warning y primary del parámetro variant.

Eliminado

  • @sas/wc-stic-chip
    • Eliminado el añadido automático de '*' al final del label cuando un chip es required.

Corregido

  • @sas/wc-stic-text

    • Corrección sobre la funcionalidad del texto sin espacios aplicado en otros componentes.
  • @sas/wc-stic-chip-text

    • Eliminada la aparición texto "undefined" cuando se hace reset y no tiene valor por defecto.
  • @sas/wc-stic-chip-select

    • Emitir evento changed cuando se elimina el valor.

Candidatos para la siguiente versión

¿Te has planteado alguna vez cómo los microfrontends pueden transformar el desarrollo y la escalabilidad de tus aplicaciones frontend?

Tenemos buenas noticias! Publicamos un nuevo apartado de Preguntas y Respuestas sobre Microfrontends que aborda todos esos aspectos clave en el diseño y desarrollo de microfrontales.

¿Quieres saber más? Descubre todos los detalles de nuestras normativas y empieza a crear Microfrontends de calidad, escalables y alineados con las mejores prácticas del sector. ¡El futuro del desarrollo frontend ya está aquí! 💻✨

Se ha publicado una importante actualización sobre los métodos y criterios a seguir en la Evaluación de Seguridad dentro del ámbito de la Oficina de Calidad de la STIC. Pretende servir de guía para la realización de pruebas de seguridad de las aplicaciones y servicios web cuyo objetivo es reforzar la protección de la aplicación ante posibles amenazas. Esta normativa, que ya está disponible en su portal oficial, introduce una serie de directrices clave para garantizar una mayor protección de los sistemas y servicios frente a las amenazas cibernéticas y otros riesgos asociados a la seguridad de la información.

¿Por qué es importante?

En un mundo cada vez más digitalizado, la seguridad de los datos y sistemas administrativos es esencial para proteger tanto a los usuarios como a las instituciones. La nueva normativa establece un marco más robusto y detallado para evaluar los riesgos de seguridad, identificando no solo las amenazas potenciales, sino también los controles necesarios para mitigarlas.

A través de la implementación de un enfoque sistemático y actualizado, se busca:

  • Fortalecer la protección de la información sensible que maneja la administración.
  • Asegurar la continuidad de los servicios públicos, minimizando los riesgos derivados de incidentes de seguridad.
  • Garantizar el cumplimiento de las normativas y regulaciones europeas y nacionales en materia de protección de datos y ciberseguridad.

¿Qué incluye?

Los puntos clave de la publicación incluyen:

  1. Métodos para la evaluación de riesgos: Se detalla cómo se deben llevar a cabo las evaluaciones de seguridad, proporcionando una metodología clara y efectiva para la identificación, análisis y gestión de riesgos asociados a la tecnología y los sistemas utilizados en los desarrollos software.

  2. Criterios para la implementación de medidas de seguridad: Además de los métodos de evaluación, también se especifican los criterios para la adopción de medidas correctivas y preventivas, lo que facilita hacer frente a cualquier amenaza que pueda surgir.

  3. Monitoreo y mejora continua: Un aspecto fundamental contemplado es la obligación de llevar a cabo un proceso de seguimiento continuo, con el objetivo de adaptar las estrategias de seguridad a las nuevas amenazas y avances tecnológicos. La mejora constante es clave para mantener la protección a largo plazo.

¿A quién afecta?

La publicación está dirigida principalmente a todas las áreas de la STIC, entidades y organismos que forman parte de la DGSIC , incluyendo servicios, departamentos y dependencias que manejan información sensible y sistemas críticos. Todos estos actores deberán ajustar sus procedimientos y prácticas de seguridad a los criterios establecidos, asegurando que las evaluaciones de seguridad sean rigurosas y efectivas.

¿Cómo acceder?

La normativa está disponible en el portal público Gobernanza y Calidad de la Subdirección de las Tecnologías de la Información y Comunicaciones (STIC), a través de este enlace directo, donde los interesados pueden consultar todos los detalles sobre el método y los criterios para la evaluación de la seguridad.

Un paso hacia una administración más segura

Este avance refuerza el compromiso con la seguridad cibernética y la protección de datos personales, y es un paso fundamental hacia la consolidación de una administración pública más transparente, moderna y segura. Sin duda, ésta normativa contribuirá a mejorar la confianza de los ciudadanos en los servicios digitales, al mismo tiempo que fortalece las capacidades de los organismos públicos para afrontar los desafíos de la seguridad informática.

¡ La seguridad es tarea de todos !


La versión 1.44.0 del catálogo de componentes web transversal, se ha liberado en los repositorios digitales de medios de la STIC.

Podréis consultarlos desde el Storybook del SAS.

Otros recursos

Recordad que el acceso a los Storybook es a través de la red corporativa del SAS.

Para cualquier duda pueden escribirnos a la Lista de Arquitectura( l-arquitectura.stic.sspa@juntadeandalucia.es ) y trataremos de daros soporte con la mayor brevedad que nos sea posible

 


CHANGELOG

Añadido

  • @sas/wc-stic-sheet-standard
  • @sas/wc-stic-sheet-modal
  • @sas/wc-stic-sheet-modal-overlay

Modificaciones en componentes existentes

  • @sas/stic-primary-button, @sas/stic-secondary-button y @sas/stic-tertiary-button

    • Añadido mínimo y máximo al ancho del botón.
  • @sas/wc-stic-input-radio

    • Añadido el parámetro helperText.

Corregido

  • @sas/wc-stic-radio, @sas/wc-stic-input-radio

    • Modificación visual del componente de acuerdo al sistema de diseño.
  • @sas/wc-stic-filters

    • Agrupados los filtros fijos obligatorios y opcionales en el mismo set.

Candidatos para la siguiente versión

La versión 1.43.0 del catálogo de componentes web transversal, se ha liberado en los repositorios digitales de medios de la STIC.

Podréis consultarlos desde el Storybook del SAS.

Otros recursos

Recordad que el acceso a los Storybook es a través de la red corporativa del SAS.

Para cualquier duda pueden escribirnos a la Lista de Arquitectura( l-arquitectura.stic.sspa@juntadeandalucia.es ) y trataremos de daros soporte con la mayor brevedad que nos sea posible

 


CHANGELOG

Corregido

  • @sas/wc-stic-chip

    • Modificado CSS para arreglar el overflow del label que hacía que el icono saliera fuera del contenedor.
  • @sas/wc-stic-filters

    • Corregido comportamiento de filtro opcional visible cuando se elimina su valor.

Candidatos para la siguiente versión

La versión 1.42.0 del catálogo de componentes web transversal, se ha liberado en los repositorios digitales de medios de la STIC.

Podréis consultarlos desde el Storybook del SAS.

Otros recursos

Recordad que el acceso a los Storybook es a través de la red corporativa del SAS.

Para cualquier duda pueden escribirnos a la Lista de Arquitectura( l-arquitectura.stic.sspa@juntadeandalucia.es ) y trataremos de daros soporte con la mayor brevedad que nos sea posible

 


CHANGELOG

Añadido

Publicación de nuevos componentes/especializaciones

  • @sas/wc-stic-button-set

Modificaciones en componentes existentes

  • @sas/wc-stic-link-button

    • Añadido el evento linkbutton:click.
  • @sas/wc-stic-chip-date, @sas/wc-stic-chip-date-range, @sas/wc-stic-chip-text

    • Añadida la propiedad open al componente.
  • @sas/wc-stic-chip-filter-set

    • Añadido al modelo de datos SticFilterChipSetBaseType la propiedad open.
  • @sas/wc-stic-dropdown-template

    • Añadido los eventos dropdown:open y dropdown:close al componente.

Modificado

  • @sas/wc-stic-table
    • Modificación visual del header de acuerdo a la versión 1.5 del sistema de diseño.

Corregido

  • @sas/wc-stic-select-v2

    • Arreglado el comportamiento de la variable value cuando no se encuentra dentro del dataSource.
  • @sas/wc-stic-filters

    • Corregido orden al añadir un filtro.

Candidatos para la siguiente versión


Consulta lista completa

No se puede representar {include}. No se ha encontrado la página incluida.

Nos complace anunciar el lanzamiento de un innovador servicio de pruebas de seguridad dinámicas en la Oficina de Calidad de la STIC. En un mundo cada vez más digital, donde las amenazas cibernéticas evolucionan constantemente, la seguridad de nuestras aplicaciones web es más crítica que nunca. Conscientes de esta realidad, hemos desarrollado este servicio para llevar a cabo una capa adicional de protección que garantice la integridad y la confianza en nuestros sistemas. 

Este servicio ha sido alineado con la Unidad de Seguridad TIC (USTIC) quien actualmente lleva a cabo la evaluación de seguridad sobre las aplicaciones software y, a partir de ahora será complementada con pruebas intrusivas ejecutadas por la Oficina de Calidad.

¿Qué son las Pruebas de Seguridad Dinámicas?

Las pruebas de seguridad dinámicas se centran en evaluar la seguridad de una aplicación mientras está en funcionamiento. A través de simulaciones de ataques reales, este enfoque nos permite identificar vulnerabilidades en tiempo real y corregirlas antes de que puedan ser explotadas. Nuestro nuevo servicio se integra perfectamente en el ciclo de desarrollo, asegurando que la seguridad se convierta en un componente fundamental desde las primeras etapas del proyecto.

Beneficios Clave del Servicio

  1. Identificación Proactiva de Vulnerabilidades: Detectamos e informamos problemas de seguridad antes de que lleguen al entorno productivo.
  2. Mejora Continua: Generamos informes detallados que facilitan la comprensión de las vulnerabilidades y proporcionan recomendaciones claras para su mitigación.

¿Qué Esperar de Este Servicio?

Al complementar la evaluación de seguridad llevada a cabo por USTIC con estas pruebas de seguridad dinámicas, se obtendrá un análisis exhaustivo de las aplicaciones que junto con un conjunto de acciones recomendadas pretende fortalecer la seguridad. Este enfoque no solo ayuda a proteger los activos digitales, sino que también fomenta la confianza de sus usuarios y partes interesadas.

Conclusión

La seguridad no es un destino, sino un viaje continuo. Con nuestro nuevo servicio de pruebas de seguridad dinámicas, estamos comprometidos a ayudar a los responsables de los productos software y equipos de trabajo a navegar por este camino con confianza. Si desea obtener más información o programar una evaluación de seguridad, en el cátalogo de servicios está incluido el detalle sobre el alcance y las condiciones para la prestación del mismo. No dude en ponerse en contacto con la Oficina de Calidad si necesita ayuda para planificar la ejecución de este servicio.


¡Estamos emocionados de dar este paso hacia un futuro más seguro y protegido!


La versión 1.41.0 del catálogo de componentes web transversal, se ha liberado en los repositorios digitales de medios de la STIC.

Podréis consultarlos desde el Storybook del SAS.

Otros recursos

Recordad que el acceso a los Storybook es a través de la red corporativa del SAS.

Para cualquier duda pueden escribirnos a la Lista de Arquitectura( l-arquitectura.stic.sspa@juntadeandalucia.es ) y trataremos de daros soporte con la mayor brevedad que nos sea posible

 


CHANGELOG

Modificado

  • @sas/wc-stic-input-number

    • Eliminada la visualización del steeper.
  • @sas/wc-stic-tag-asistencial

    • Modificados todos los iconos (svg) a versiones finales.

Candidatos para la siguiente versión


Consulta lista completa

No se puede representar {include}. No se ha encontrado la página incluida.

La versión 1.40.0 del catálogo de componentes web transversal, se ha liberado en los repositorios digitales de medios de la STIC.

Podréis consultarlos desde el Storybook del SAS.

Otros recursos

Recordad que el acceso a los Storybook es a través de la red corporativa del SAS.

Para cualquier duda pueden escribirnos a la Lista de Arquitectura( l-arquitectura.stic.sspa@juntadeandalucia.es ) y trataremos de daros soporte con la mayor brevedad que nos sea posible

 


CHANGELOG

Añadido

  • @sas/wc-stic-icon

    • Añadido el atributo badgeSize.
  • @sas/wc-stic-navigation

    • Añadida propiedad size al componente, con los valores sm y md (por defecto).

Modificado

  • @sas/wc-stic-navigation-rail, @sas/wc-stic-navigation-drawer, @sas/wc-stic-navigation, @sas/wc-stic-navigation-rail-template
    • Modificación visual del componente de acuerdo a la versión 1.5 del sistema de diseño.

Candidatos para la siguiente versión


Consulta lista completa

No se puede representar {include}. No se ha encontrado la página incluida.

La versión 1.39.0 del catálogo de componentes web transversal, se ha liberado en los repositorios digitales de medios de la STIC.

Podréis consultarlos desde el Storybook del SAS.

Otros recursos

Recordad que el acceso a los Storybook es a través de la red corporativa del SAS.

Para cualquier duda pueden escribirnos a la Lista de Arquitectura( l-arquitectura.stic.sspa@juntadeandalucia.es ) y trataremos de daros soporte con la mayor brevedad que nos sea posible

 


CHANGELOG

Añadido

Publicación de nuevos componentes/especializaciones

  • @sas/wc-stic-filters-area

Modificaciones en componentes existentes

  • @sas/wc-stic-alert

    • Modificación visual del componente de acuerdo al sistema de diseño v1.5.
    • Creado evento alert:closebuttonClick.
  • @sas/wc-stic-filter-chip-set

    • Añadido al modelo de datos SticFilterChipSetTextType la propiedad valueOperator.
  • @sas/wc-stic-filter-visibility

    • Añadida la propiedad infoButton.
    • Añadido el evento sticFilterVisibility:clickInfoButton.

Modificado

  • @sas/wc-stic-result, @sas/wc-stic-table
    • Modificación visual del componente de acuerdo a la versión 1.5 del sistema de diseño.

Corregido

  • @sas/wc-stic-theme
    • Adaptación a tokens v1.5.1 del Sistema de Diseño.

Deprecado

  • @sas/wc-stic-result
    • Deprecada la propiedad divider.

Candidatos para la siguiente versión


Consulta lista completa

No se puede representar {include}. No se ha encontrado la página incluida.

La versión 1.38.0 del catálogo de componentes web transversal, se ha liberado en los repositorios digitales de medios de la STIC.

Podréis consultarlos desde el Storybook del SAS.

Otros recursos

Recordad que el acceso a los Storybook es a través de la red corporativa del SAS.

Para cualquier duda pueden escribirnos a la Lista de Arquitectura( l-arquitectura.stic.sspa@juntadeandalucia.es ) y trataremos de daros soporte con la mayor brevedad que nos sea posible

 

CHANGELOG

Modificado

  • @sas/wc-stic-expander
    • Modificación visual y funcional del componente de acuerdo al sistema de diseño v1.5.

Corregido

  • @sas/wc-stic-table
    • El icono de ordenación de columna se mantendrá visible en caso de que haya establecida una ordenación.

Candidatos para la siguiente versión


Consulta lista completa

No se puede representar {include}. No se ha encontrado la página incluida.


Estado

VIGENTE

Partes interesadas

TAGS

AUTENTICACION SEGURIDAD

Tomada el

 

Documentación Asociada

  Fichero Modificado
Archivo PNG image-2024-2-15_13-55-28.png 19/09/2024 by CARLOS GONZALEZ SANTIAGO
Archivo PNG image-2024-2-15_13-38-8.png 19/09/2024 by CARLOS GONZALEZ SANTIAGO
Archivo PNG image-2024-2-15_13-54-3.png 19/09/2024 by CARLOS GONZALEZ SANTIAGO
Archivo PNG image-2024-2-15_14-1-39.png 19/09/2024 by CARLOS GONZALEZ SANTIAGO
Archivo PNG image-2024-2-15_13-48-55.png 19/09/2024 by CARLOS GONZALEZ SANTIAGO

Solución Afectada

TODAS


Asunto a Decidir

Describe brevemente la decisión arquitectónica tomada.

Se requiere decidir el mecanismo de autenticación y/o autorización para la comunicación entre sistemas del SAS teniendo en cuenta los requisitos minimos de seguridad exigibles en el SAS a un sistema de registro de actividad con validez legal. 

Identificación de la decisión

Describe brevemente la decisión arquitectónica tomada.

Consideramos que la alternativa 3 es la que presenta un mejor balance coste beneficio, y que nos mantiene un  modelo claro y sencillo, con capacidades de administración de los clientes autorizados a verter auditoria, manteniéndose además dentro de los estándares, y con un impacto en costes muy reducido tanto evidentes en MVP como ocultos cuando se inicie el proceso de integración en las aplicaciones terceras.

Keycloak ya proporciona una solución para el problema planteado  esta solución  se apoya en un estándar como OAuth2.0. Al usar la misma herramienta y los mismos recursos que para el resto de autentificaciones evitamos introducir un sistema adicional,  duplicidades, el aumento de la complejidad y solapamientos con los sobrecostes que conlleva. mantenemos el sistema simple

El uso de un clientId con un secret asociado es en gran medida equivalente a la solución de un API-KEY dónde usamos un ID del cliente y una secret para obtener un token autentificado seguro con los roles y autorizaciones que le corresponda. Desde el punto de vista de la máquina invocante varia ligeramente el flujo ya que invoca a la URL proporcionada con el clientId y el password y obtiene el token generado por keycloak, a partir de este punto el funcionamiento/flujo es el estándar para cualquier autentificación por Oauth2.0

Al seguir la estrategia con Keycloack no es necesario tener diferentes estrategias de seguridad. por ejemplo un servicio invocado por un usuario y por una máquina no necesita una autentificación OAUTH y apy-key, le basta con OAUTH.

Keycloak es altamente configurable y adaptable permitiéndonos adaptar la seguridad al nivel exacto que se requiera para cada cliente; es mas completo y flexible. Una vez establecida la configuración deseada se puede generar un JSON con dicha configuración e importarlo para los nuevos clientes, convirtiendo la creación de nuevos clientes en algo trivial.

Al mantenernos en la opción de keycloak obtenemos una solución cercana a API-KEY en sencillez, con facilidad para operarlo e integrarlo en DEVOPS.

Contexto

Con la proliferación de la arquitectura de referencia y los desarrollos basados en microservicios unida a la estrategia de autenticación y autorización centralizada (SSO) de la organización.

Por lo tanto, se solicita una propuesta de mecanismo de autenticación y autorización que sea adecuado para asegurar la comunicación entre sistemas.


Alternativas Consideradas

Se analiza el uso de API Keys y de Client Secret como mecanismo de autenticación y autorización para la comunicación entre sistemas del SAS. Esta propuesta se divide en tres alternativas:

Alternativa 1:

Api key para todos los sistemas igual. Guardar el valor en k8s y obtenerlo desde una variable de entorno. Es sólo autenticación, no incluye autorización (es decir, cualquier sistema puede logar cualquier evento)

Alternativa 2:

Incluir una autorización por cada sistema productor. En este caso habría que disponer de una persistencia que almacenara API-KEY, sistema y eventos autorizados a logar. Esta alternativa es más elegante aunque más costosa, y permite un grano más fino de autenticación y autorización. 

Alternativa 3:

Otra alternativa al Ali-key es el uso de Keycloak con Client Id y secret. Este mecanismo permite la autentificación y autorización entre máquinas. 


Alternativa 1

Las API Keys permiten autenticar y autorizar a un sistema tercero a acceder al recurso del sistema responsable del mismo. Para ello, cada sistema tercero debe obtener una API Key y una API Secret Key.

Posibilidades
  • Autenticación y autorización: Las API Keys permiten autenticar y autorizar a un sistema tercero a acceder al recurso del sistema responsable del mismo.
  • Autorización: Las API Keys permiten autorizar a un sistema tercero a acceder al recurso del sistema responsable.
  • Flexibilidad: Las API Keys pueden ser utilizadas para restringir el acceso a al recurso del sistema  en función de las necesidades de cada sistema tercero.
  • Seguridad: Las API Keys pueden ser utilizadas para proteger el recurso del sistema de accesos no autorizados.
Ventajas
  • Fácil implementación: Las API Keys son fáciles de implementar y utilizar.
  • Escalabilidad: Las API Keys son escalables y pueden ser utilizadas para gestionar un gran número de sistemas terceros.
  • Coste: Las API Keys son una solución de bajo coste.


Desventajas
  • Requiere gestión: Las API Keys requieren una gestión adecuada para evitar que sean utilizadas de forma fraudulenta.
  • No es adecuada para todos los casos: Las API Keys no son adecuadas para casos en los que se requiere una autenticación y autorización más compleja, como la autenticación multifactor.
  • Nivel de seguridad muy básico: La API Key no puede ser revocada fácilmente sin altos costes, dado que es única cualquier sistema que la conozca puede hacer uso de ella para registrar auditoria, y el control es prácticamente inexistente una vez esté entregada al primer proyecto. 
Coste Adopción

Dentro de las ventajas por parte de se plantea que este sistema es de bajo coste pero no se está contando con la duplicidad que implica la multiplicidad en los sistemas de autenticación, así pues la evaluación de coste que se hace al respecto es la siguiente:

  • Coste de API Keys
  • Coste Integración con Autentificación Keycloak (la autentificación máquina - máquina no es excluyente con usuario - máquina por lo que el sistema destino debe soportar ambas autentificaciones)
  • Coste por solapamiento. Estaríamos tratando la autentificación con dos sistemas diferentes con lo que tenemos duplicidades que complican la operación. 
  • Coste de operación (Es necesario catalogar y administrar los api-key, esta es una tarea fundamentalmente manual)

Así pues el coste sería:

  • Coste de API Keys → Coste bajo
  • Coste Integración con Autentificación Keycloak → Coste medio (aumenta la complejidad del software en caso de ser necesaria)
  • Coste por solapamiento. → Coste alto 
  • Coste de operación→ Coste medio


Alternativa 2

Realmente esta alternativa es una expansión de la alternativa 1. en esta alternativa  plantea lo siguiente "Incluir una autorización por cada sistema productor. En este caso habría que disponer de una persistencia que almacenara API-KEY, sistema y eventos autorizados a logar. Esta alternativa es más elegante aunque más costosa, y permite un grano más fino de autenticación y autorización."

Ventajas
  • Fácil implementación: Las API Keys son fáciles de implementar y utilizar.
  • Escalabilidad: Las API Keys son escalables y pueden ser utilizadas para gestionar un gran número de sistemas terceros.
  • Coste: Las API Keys son una solución de bajo coste.
  • Grano fino de autorización
Desventajas
  • Requiere gestión: Las API Keys requieren una gestión adecuada para evitar que sean utilizadas de forma fraudulenta.
  • No es adecuada para todos los casos: Las API Keys no son adecuadas para casos en los que se requiere una autenticación y autorización más compleja, como la autenticación multifactor.
  • Nivel de seguridad muy básico: La API Key no puede ser revocada fácilmente sin altos costes, dado que es única cualquier sistema que la conozca puede hacer uso de ella para registrar auditoria, y el control es prácticamente inexistente una vez esté entregada al primer proyecto. 
  • Requiere de un software adicional para poder gestionar adecuadamente todas las API-Keys
Coste Adopción

Dentro de las ventajas por parte de  se plantea que este sistema es de bajo coste pero no se está contando con la duplicidad que implica la multiplicidad en los sistemas de autenticación, así pues la evaluación de coste que se hace al respecto es la siguiente:

  • Coste de API Keys
  • Coste Integración con Autentificación Keycloak (la autentificación máquina - máquina no es excluyente con usuario - máquina por lo que el sistema destino debe soportar ambas autentificaciones)
  • Coste por solapamiento. Estaríamos tratando la autentificación con dos sistemas diferentes con lo que tenemos duplicidades que complican la operación. 
  • Coste de operación(Es necesario catalogar y administrar los api-key, esta es una tarea fundamentalmente manual)

Así pues el coste sería:

  • Coste de API Keys → Coste bajo
  • Coste Integración con Autentificación Keycloak → Coste medio (aumenta la complejidad del software en caso de ser necesaria)
  • Coste por solapamiento. → Coste alto 
  • Coste de operación→ Coste medio


Alternativa 3
En esta alternativa planteamos el uso de Keycloak, concretamente la creación de clientes con autentificación basada en clientId y secret. En esta alternativa el productor solicita un token mediante el uso del client Id y un secret y a partir de ese momento usa el token para la comunicación mediante el estándar oauth2.0.
Posibilidades
  • Autenticación y autorización: Los ClientId - Secrets permiten autenticar y autorizar a un sistema tercero generando un token de acceso a los recursos del sistema que estén autorizados.
  • Autorización: Los ClientId - Secrets permiten autorizar a un sistema tercero a acceder a los recursos del sistema.
  • Flexibilidad: Los ClientId - Secrets pueden ser utilizadas para restringir el acceso a los recursos del sistema en función de las necesidades de cada sistema tercero.
  • Seguridad: Los ClientId - Secrets pueden ser utilizadas para proteger los recursos del sistema de accesos no autorizados.
  • Revocación: El uso de clientes y tokens oauth garantizan la posibilidad de revocación.
  • Estándares de seguridad: Keycloak se integra con Oauth1.0, Oauth2.0, SAML.
Ventajas
  • Fácil implementación: Los clientes Keycloak son fáciles de implementar y utilizar y mantener. No requiere de herramientas adicionales
  • Escalabilidad: Los clientes Keycloak son escalables y pueden ser utilizadas para gestionar un gran número de sistemas terceros.
  • Coste: Los clientes Keycloak son una solución de bajo coste.
  • Flexibilidad: Permite flujos complejos de autentificación y múltiples sistemas de autentificación.
  • Grano fino de autorización
Desventajas
  •  Requiere configuración: Los clientes requieren configuración en Keycloak en el Realm correspondiente.
Coste Adopción
  • Coste sistema →No aplica (usa keycloak)
  • Coste Integración con Autentificación Keycloak → No aplica (Es el mismo sistema)
  • Coste por solapamiento. → No aplica (no existen duplicidades ya que solo un sistema)
  • Coste de operación Coste medio (coste de configuración del cliente correspondiente)

Planteamos una pequeña POC de ejemplo

POC Client Id

Planteamos un realm "api". Sobre este realm creamos un cliente "api-n" de tipo OpenID Connect tal y como se muestra en la captura siguiente.


SAS 

Dentro de las configuraciones de las capacidades de este cliente activamos "Client authentication" si deseamos una autorización de grano fino activamos la autorización. a continuación marcamos los flujos de autentificación que deseamos tener activos dentro de los parámetros OAuth2.0.


Una vez que hemos creado nuestro cliente acudimos a la pestaña Credentials, generamos un secret aleatorio e indicamos que la autentificación será mediante  "Client Id and Secret". para una POC no entraremos en más detalles.


Cuando hacemos una petición postman para obtener el token podemos ver que la autentificación es correcta.

Podemos ver que el contenido del token es correcto y está activo, por lo tanto la autentificación ha sido correcta.



El impacto en el microservicio que debe validar el token hay que considerar los siguientes cambios:

microprofile-config.properties
mp.jwt.token.header=Authorization
mp.jwt.token.cookie=Bearer

 

server.xml
<feature>microProfile-3.3</feature>


<mpJwt id="defaultmpjwt" jwksUri="https://keycloak.ejemplo.org/auth/realms/sistema-n/protocol/openid-connect/certs" issuer="https://keycloak.ejemplo.org/auth/realms/sistema-n"
	userNameAttribute="azp">
		<audiences>ALL_AUDIENCES</audiences>
</mpJwt>

El método que debe validar el token se debe anotar con:  @RolesAllowed("LISTA-ROLES-AUTORIZADOS")





Decisión Tomada

Describe brevemente la decisión arquitectónica tomada.

Consideramos que la alternativa 3 es la que presenta un mejor balance coste beneficio, y que nos mantiene un  modelo claro y sencillo, con capacidades de administración de los clientes autorizados a verter auditoria, manteniéndose además dentro de los estándares, y con un impacto en costes muy reducido tanto evidentes en MVP como ocultos cuando se inicie el proceso de integración en las aplicaciones terceras.

Keycloak ya proporciona una solución para el problema planteado  esta solución  se apoya en un estándar como OAuth2.0. Al usar la misma herramienta y los mismos recursos que para el resto de autentificaciones evitamos introducir un sistema adicional,  duplicidades, el aumento de la complejidad y solapamientos con los sobrecostes que conlleva. mantenemos el sistema simple

El uso de un clientId con un secret asociado es en gran medida equivalente a la solución de un API-KEY dónde usamos un ID del cliente y una secret para obtener un token autentificado seguro con los roles y autorizaciones que le corresponda. Desde el punto de vista de la máquina invocante varia ligeramente el flujo ya que invoca a la URL proporcionada con el clientId y el password y obtiene el token generado por keycloak, a partir de este punto el funcionamiento/flujo es el estándar para cualquier autentificación por Oauth2.0

Al seguir la estrategia con Keycloack no es necesario tener diferentes estrategias de seguridad. por ejemplo un servicio invocado por un usuario y por una máquina no necesita una autentificación OAUTH y apy-key, le basta con OAUTH.

Keycloak es altamente configurable y adaptable permitiéndonos adaptar la seguridad al nivel exacto que se requiera para cada cliente; es mas completo y flexible. Una vez establecida la configuración deseada se puede generar un JSON con dicha configuración e importarlo para los nuevos clientes, convirtiendo la creación de nuevos clientes en algo trivial.

Al mantenernos en la opción de keycloak obtenemos una solución cercana a API-KEY en sencillez, con facilidad para operarlo e integrarlo en DEVOPS.

Consecuencias

Describe brevemente la decisión arquitectónica tomada.

  • Es necesario categorizar los clientes determinando las características que se requieren para cada tipo. Definidos en Keycloak los tipos de clientes y las configuraciones óptimas se puede mecanizar la creación de nuevos clientes.
  • Con el uso de Keycloak se podrá disponer de un control claro y completo de todas las integraciones que se realizan con un API a través de la estructura REALM/CLIENT pudiendo revocar una integración concreta cuando sea necesaria.
  • No se requerirá de nuevas herramientas en el esquema de seguridad ni aplicativos con esquemas de seguridad externos o independientes.
  • Cualquier necesidad no cubierta se puede extender mediante SPI por lo que se deberá plantear y estudiar cada caso.
  • El coste de adopción de esta solución en auditoria implica configurar tres ficheros con configuraciones muy concretas y fáciles de aplantillar por lo que se puede concluir que es un coste muy bajo.


Operación
Creación Cliente

Creamos un cliente de tipo OpenID Connect en el realm deseado tal y como se muestra en la captura siguiente.


Dentro de las configuraciones de las capacidades de este cliente activamos "Client authentication" si deseamos una autorización de grano fino activamos la autorización. a continuación marcamos los flujos de autentificación que deseamos tener activos dentro de los parámetros OAuth2.0.


Una vez que hemos creado nuestro cliente acudimos a la pestaña Credentials, generamos un secret aleatorio e indicamos que la autentificación será mediante  "Client Id and Secret". para una POC no entraremos en más detalles.


En los mapeos del token se requiere añadir upn y groups con los roles, ningún otro mapeo en especial.

Revocación:

Desde la consola de keycloak se puede revocar una sesión concreta de un cliente dado.

Deshabilitar el cliente o incluso eliminándolo causa que un clientId ya no pueda autentificar, lo equivale a una revocación aunque las sesiones activas continuarían vivas y una vez cerradas no se pueden crear nuevas para ese  cliente.

La versión 1.37.0 del catálogo de componentes web transversal, se ha liberado en los repositorios digitales de medios de la STIC.

Podréis consultarlos desde el Storybook del SAS.

Otros recursos

Recordad que el acceso a los Storybook es a través de la red corporativa del SAS.

Para cualquier duda pueden escribirnos a la Lista de Arquitectura( l-arquitectura.stic.sspa@juntadeandalucia.es ) y trataremos de daros soporte con la mayor brevedad que nos sea posible

CHANGELOG

Añadido

  • storybook
    • Actualizada versión de storybook a 8.2.9

Modificaciones en componentes existentes

  • @sas/wc-stic-chip, @sas/wc-stic-chip-date, @sas/wc-stic-chip-text

    • Añadida la propiedad required al componente.
  • @sas/wc-stic-chip-select, @sas/wc-stic-chip-select-multiple

    • Añadida la propiedad required y reset al componente.
  • @sas/wc-stic-chip-set

    • Añadido al modelo de datos SticFilterChipSetBaseType la propiedad required.
  • @sas/wc-stic-paginator

    • Añadidas las propiedades hidePages y totalResultsPosition.

Modificado

  • @sas/wc-stic-card, @sas/wc-stic-paginator
    • Modificación visual del componente de acuerdo al sistema de diseño v1.5.

Corregido

  • @sas/wc-stic-input

    • Corregida la documentación en el fichero README.md para incluir la importación de especializaciones de manera individual.
  • @sas/wc-stic-card-group

    • Corrección del renderizado de la card individual dentro del componente en storybook.
    • Corrección de la documentación.
  • @sas/wc-stic-filters

    • Corregido comportamiento al pulsar el botón "Eliminar".

Candidatos para la siguiente versión


Consulta lista completa

No se puede representar {include}. No se ha encontrado la página incluida.

La versión 1.36.0 del catálogo de componentes web transversal, se ha liberado en los repositorios digitales de medios de la STIC.

Podréis consultarlos desde el Storybook del SAS.

Otros recursos

Recordad que el acceso a los Storybook es a través de la red corporativa del SAS.

Para cualquier duda pueden escribirnos a la Lista de Arquitectura( l-arquitectura.stic.sspa@juntadeandalucia.es ) y trataremos de daros soporte con la mayor brevedad que nos sea posible


CHANGELOG

Añadido

Publicación de nuevos componentes/especializaciones

  • @sas/wc-stic-collapse
  • @sas/wc-stic-sticky-panel

Modificaciones en componentes existentes

  • @sas/wc-stic-filter-chip-set

    • Añadido el evento filterChipSet:chipChanged.
  • @sas/stic-icon-button

    • Añadida la propiedad iconFilled.

Modificado

  • @sas/wc-stic-input-time, @sas/wc-stic-breadcrumbs, @sas/wc-stic-time
    • Modificación visual del componente de acuerdo al sistema de diseño v1.5.

Corregido

  • @sas/wc-stic-input-file

    • Arreglado el comportamiento al seleccionar un fichero.

Candidatos para la siguiente versión


Consulta lista completa

No se puede representar {include}. No se ha encontrado la página incluida.

La versión 1.35.0 del catálogo de componentes web transversal, se ha liberado en los repositorios digitales de medios de la STIC.

Podréis consultarlos desde el Storybook del SAS.

Otros recursos

Recordad que el acceso a los Storybook es a través de la red corporativa del SAS.

Para cualquier duda pueden escribirnos a la Lista de Arquitectura( l-arquitectura.stic.sspa@juntadeandalucia.es ) y trataremos de daros soporte con la mayor brevedad que nos sea posible

CHANGELOG

Añadido

Publicación de nuevos componentes/especializaciones

  • @sas/wc-stic-filter-filters

Modificado

  • @sas/wc-stic-select-v2

    • Modificada documentación sobre value y selected, tanto en las interfaces como en los ejemplos.
  • @sas/wc-stic-table

    • Modificación visual del comportamiento de los iconos de ordenación de columna.

Corregido

  • @sas/wc-stic-input-file

    • Arreglado el comportamiento al seleccionar un fichero.

Candidatos para la siguiente versión


Consulta lista completa

No se puede representar {include}. No se ha encontrado la página incluida.