La Junta de Andalucía ha desplegado en producción Port@Firmas 3.7.13, una versión que introduce cambios de gobernanza sobre las aplicaciones integradas y consolida la transición hacia servicios REST. A partir de esta versión, las nuevas aplicaciones integradas solo pueden utilizar la nueva fachada REST.
La actualización, publicada el 15 de septiembre, incorpora además campos para identificar a la persona responsable, su correo electrónico y el organismo propietario de cada aplicación. También elimina a los administradores delegados los permisos para crear o modificar aplicaciones.
Estas medidas muestran que la modernización de una plataforma de firma no se limita a renovar APIs. También exige saber quién es responsable de cada integración y reducir cambios no controlados en un servicio corporativo.
Nuevas aplicaciones, solo mediante la nueva fachada REST
La decisión más relevante es que las nuevas integraciones deben utilizar la nueva fachada REST. La fuente oficial no afirma que todas las integraciones existentes deban migrar inmediatamente.
Esto permite una transición gradual: las nuevas aplicaciones nacen sobre la arquitectura objetivo mientras los sistemas heredados pueden seguir un calendario específico.
El patrón reduce deuda tecnológica a futuro.
Tres nuevos campos para saber quién responde por cada integración
Port@Firmas incorpora persona responsable, correo de contacto y organismo propietario. Estos metadatos son fundamentales cuando existen decenas o cientos de aplicaciones.
Ante una incidencia, actualización o vulnerabilidad, el equipo central necesita localizar rápidamente al responsable funcional o técnico.
El gobierno de activos empieza por saber quién utiliza cada servicio.
Menos permisos para administradores delegados
La versión elimina permisos de creación y modificación de aplicaciones a administradores delegados.
El cambio refuerza control central sobre el catálogo de integraciones. Reducir privilegios puede evitar configuraciones inconsistentes o altas sin la revisión necesaria.
La aplicación del mínimo privilegio es una práctica alineada con el Esquema Nacional de Seguridad.
REST como arquitectura objetivo
Las APIs REST facilitan integraciones más alineadas con arquitecturas web modernas. Permiten trabajar con contratos claros y herramientas de desarrollo ampliamente disponibles.
La Junta lleva meses publicando nuevas versiones de esta fachada, lo que indica que la transición no es un cambio puntual.
El mismo ecosistema incluye servicios de @firma y otras piezas corporativas.
Una corrección visible para los usuarios: tildes en correos
La versión 3.7.13 corrige caracteres extraños en el cuerpo de correos cuando los textos contienen tildes.
Puede parecer un detalle menor, pero los errores de codificación deterioran la confianza y pueden afectar comunicaciones oficiales.
La calidad del servicio digital incluye también la correcta representación del idioma.
Inventario y contacto operativo
Los nuevos campos permiten construir un inventario más útil. No basta con conocer el nombre técnico de una aplicación; hay que saber a quién avisar.
Esta información puede utilizarse para campañas de migración, revisiones de seguridad y retirada de integraciones sin uso.
El principio es similar al de las plataformas de gobernanza de datos como HAL en Aragón: cada activo necesita responsable.
Planificar la migración de integraciones antiguas
Aunque la nota no establece una migración retroactiva general, las organizaciones deberían identificar qué sistemas siguen utilizando fachadas antiguas.
Un mapa de dependencias permite priorizar por criticidad y fin de soporte.
Las aplicaciones con mayor volumen o impacto deberían disponer de pruebas específicas.
Pruebas de compatibilidad
La migración entre interfaces puede cambiar formatos, autenticación o tratamiento de errores.
Los equipos necesitan probar casos positivos y negativos, así como tiempos de respuesta.
Un entorno de integración estable reduce riesgo de fallos en expedientes reales.
Firma y expediente electrónico
Port@Firmas participa en flujos donde documentos pasan por revisión y firma antes de incorporarse al expediente.
Una integración defectuosa puede bloquear resoluciones o generar documentos incompletos.
Por eso la plataforma debe tratarse como infraestructura transversal.
Observabilidad por aplicación
Los nuevos identificadores de responsable pueden combinarse con métricas de uso. Conocer qué aplicación genera errores o mayor volumen ayuda a priorizar soporte.
También permite detectar integraciones inactivas y reducir superficie.
La monitorización debe proteger datos de documentos y firmantes.
Gestión de versiones como servicio
Una fachada corporativa necesita política de versiones, fechas de deprecación y documentación.
Los consumidores deben disponer de tiempo para adaptarse.
La existencia de una versión objetivo REST facilita concentrar documentación y pruebas.
Automatización de pruebas
Los equipos pueden incorporar pruebas contractuales en pipelines CI/CD para detectar incompatibilidades antes de desplegar.
La Junta está desarrollando una cultura de automatización mediante PAD y sus activos comunes.
La combinación de APIs estables y pipelines reduce errores manuales.
Gobernanza central sin frenar a los equipos
Eliminar permisos de creación a administradores delegados puede aumentar control, pero el proceso central debe ser ágil.
Si dar de alta una aplicación tarda demasiado, los equipos buscarán atajos.
La gobernanza efectiva combina control y tiempos de servicio claros.
Documentación de cada integración
Cada alta debería incluir finalidad, responsable, entorno, autenticación y contactos.
Estos datos ayudan a auditoría y continuidad.
El catálogo puede convertirse en una fuente única para operaciones.
Seguridad de las cuentas técnicas
Las integraciones suelen utilizar credenciales de aplicación. Deben rotarse y almacenarse de forma segura.
La retirada de una aplicación debe incluir revocación.
El nuevo gobierno de responsables facilita asignar esta tarea.
Continuidad ante indisponibilidad
Los sistemas que dependen de firma deben definir qué ocurre si Port@Firmas no está disponible.
Algunos expedientes podrán esperar; otros requerirán planes de contingencia.
La criticidad debe documentarse por proceso.
Interoperabilidad y reutilización
Una plataforma común evita que cada consejería construya su propio circuito de firma.
Este enfoque coincide con la lógica de componentes reutilizables y servicios compartidos.
La reutilización permite concentrar inversión en una infraestructura robusta.
Qué no significa la versión 3.7.13
La publicación no establece que todos los sistemas existentes deban abandonar de inmediato sus interfaces anteriores.
Tampoco cambia por sí sola los requisitos jurídicos de firma.
El cambio confirmado afecta a la plataforma, su gobernanza y las nuevas integraciones.
Fuente oficial
La Junta publicó las notas de la versión 3.7.13 el 15 de septiembre de 2026.
La actualización combina arquitectura y gobierno: nuevas APIs, menos permisos de administración y más información sobre responsables. Esa combinación es clave para que un servicio transversal pueda crecer sin perder control.
El cambio afecta al alta de nuevas aplicaciones
La decisión de reservar la nueva fachada REST para nuevas integraciones crea una regla clara a partir de la cual no debería crecer la deuda tecnológica anterior.
Los equipos que comiencen un proyecto deben diseñar directamente sobre la interfaz vigente. Esto evita desplegar una aplicación nueva que nazca ya pendiente de migración.
El catálogo corporativo puede incorporar esta condición en plantillas y revisiones de arquitectura.
Un responsable identificable para cada aplicación
Los nuevos campos de persona responsable, correo y organismo propietario permiten dejar atrás catálogos donde solo aparece un nombre técnico. Esta información es decisiva cuando hay que avisar de un cambio urgente.
Los contactos deberían revisarse automáticamente o al menos de forma periódica. Una dirección asociada a una persona que cambió de puesto puede dejar el activo sin propietario real.
El organismo propietario aporta además una referencia institucional que permanece aunque cambie el responsable.
Separar administración delegada y gobierno de plataforma
Retirar a administradores delegados la creación y modificación de aplicaciones reduce el número de actores capaces de cambiar el catálogo central.
El modelo puede reservar la operación cotidiana a administradores locales y mantener las altas estructurales bajo un proceso controlado.
La medida será efectiva si el canal central responde con agilidad y no se convierte en un cuello de botella.
Preparar el apagado de fachadas antiguas
La Junta ya ha anunciado en otros avisos la inhabilitación de determinadas fachadas SOAP antiguas. El avance hacia REST debe acompañarse de un inventario de sistemas que aún dependen de tecnologías anteriores.
Cada integración necesita fecha objetivo, responsable y pruebas. Los sistemas sin mantenimiento deben recibir una estrategia específica.
El apagado ordenado evita mantener interfaces vulnerables únicamente por desconocer quién las utiliza.
Optimizar llamadas de consulta
La fachada REST v3 también ha recibido mejoras de rendimiento en su versión 1.8.7 para determinados servicios. Esto muestra que la transición no es solo una decisión de estilo arquitectónico.
Los equipos deben medir latencias y patrones de uso reales para detectar consultas costosas. El rendimiento de una API compartida afecta simultáneamente a múltiples aplicaciones.
La observabilidad por consumidor ayuda a localizar cargas anómalas y optimizar sin perjudicar al resto.
Catálogo de dependencias
Una aplicación integrada con Port@Firmas suele depender también de identidad, expediente, notificaciones o archivo. Conocer esas relaciones permite evaluar impacto de cambios.
El nuevo gobierno de aplicaciones puede evolucionar hacia un mapa de dependencias corporativo.
Este mapa facilita continuidad, auditoría y planificación de modernización.
Controles sobre el correo electrónico generado
La corrección de caracteres con tildes recuerda que los servicios transversales también producen comunicaciones visibles. Las pruebas deben incluir codificación, plantillas y accesibilidad.
Un mensaje de firma con símbolos incorrectos puede generar dudas sobre autenticidad o dificultar comprensión.
La calidad lingüística forma parte de la calidad de servicio digital.
Revisión de aplicaciones sin uso
El catálogo puede acumular integraciones creadas para proyectos ya retirados. Mantener credenciales y configuraciones innecesarias aumenta superficie de ataque.
La identificación del propietario permite preguntar si la aplicación sigue activa y cerrar accesos cuando no son necesarios.
Una campaña anual de limpieza puede reducir deuda y mejorar la fiabilidad del inventario.
Métricas para la transición REST
La Junta puede medir porcentaje de nuevas altas sobre REST, número de integraciones antiguas pendientes y volumen de llamadas por fachada.
Estos indicadores muestran si la arquitectura objetivo se está adoptando realmente.
También permiten fijar fechas de retirada basadas en datos y no en estimaciones.
Pruebas de conformidad para integradores
Un conjunto de pruebas común puede validar que las aplicaciones cumplen el contrato REST antes de conectarse a producción.
Esto reduce incidencias y ofrece a proveedores externos una referencia objetiva.
La cultura europea de pruebas de conformidad puede servir de inspiración para servicios internos.
Un onboarding técnico para nuevas integraciones
Si todas las nuevas aplicaciones deben utilizar REST, la Junta puede estandarizar su incorporación con una guía de alta, ejemplos, credenciales de prueba y casos de validación.
Un onboarding común reduce errores de proveedores y equipos internos. También permite comprobar desde el inicio que la aplicación dispone de propietario, contacto y documentación suficiente.
Convertir el alta en un proceso repetible ayuda a que el control central no ralentice proyectos.
Preparar la retirada desde el momento del alta
Todo sistema debería registrar cómo se revocarán credenciales, eliminarán configuraciones y cerrarán accesos cuando deje de utilizarse. Pensar en el final desde el inicio evita aplicaciones huérfanas.
Los nuevos campos de responsable y organismo propietario facilitan esta gestión del ciclo completo.
Port@Firmas puede así evolucionar de un catálogo de integraciones a un verdadero registro de activos con alta, mantenimiento y baja controladas.
Contratos de integración estables para proveedores
Muchas aplicaciones de la Junta son desarrolladas o mantenidas por terceros. La fachada REST debe disponer de un contrato técnico estable que pueda incorporarse a los pliegos y entregables.
Esto permite exigir que un proveedor entregue pruebas, documentación y código compatible con la arquitectura corporativa. También reduce discusiones sobre formatos o comportamientos que deberían estar definidos de antemano.
Cuando el contrato de la API cambia, la modificación debe versionarse y comunicarse para que los adjudicatarios puedan adaptarse sin interrumpir servicio.
Un historial de cambios por aplicación
Además del propietario actual, Port@Firmas puede conservar un historial de altas, modificaciones de permisos y cambios de responsable. Esta trazabilidad facilita auditorías y evita perder contexto cuando rota el personal.
El historial también permite saber qué aplicación estaba configurada de una determinada manera en el momento de una incidencia.
Gestionar el ciclo completo del activo refuerza la seguridad y reduce dependencia del conocimiento informal.
Comunicar deprecaciones con anticipación
La transición a REST será más segura si cada fachada antigua dispone de una fecha prevista de retirada y avisos escalonados. Los responsables identificados en el catálogo pueden recibir estas comunicaciones directamente.
Un calendario público para integradores evita migraciones urgentes y permite incluir el trabajo en contratos de mantenimiento. También facilita que la plataforma reduzca soporte heredado sin sorprender a aplicaciones críticas.
Mantenimiento como requisito de arquitectura
La transición REST debe quedar incorporada al mantenimiento ordinario de cada aplicación. Revisar dependencias y compatibilidad en cada renovación evita acumular otra generación de integraciones heredadas y mantiene el servicio alineado con la arquitectura corporativa.
Fotografía: Matheus Lara / Pexels.