Federación entre organizaciones: colaborar sin concesiones

Nota: Este artículo describe la arquitectura y el diseño de Mandraki. Algunas de las funcionalidades comentadas se están desplegando de forma progresiva y pueden no estar disponibles aún en todos los planes.

La colaboración empresarial no ocurre en aislamiento. Las organizaciones trabajan con socios, clientes, reguladores, contratistas y consorcios sectoriales. Las personas con las que se necesita comunicarse a menudo están fuera de la propia organización, y con frecuencia fuera de la propia plataforma de colaboración.

Las soluciones tradicionales a este problema son insatisfactorias. Puede invitar a usuarios externos como invitados a su plataforma, lo que difumina los límites de seguridad y genera carga administrativa. Puede mantener cuentas en múltiples plataformas, lo que fragmenta sus comunicaciones. O puede recurrir al correo electrónico, que no ofrece ninguna de las funcionalidades de colaboración en tiempo real que exige el trabajo moderno.

La federación entre organizaciones de Mandraki ofrece un enfoque mejor: dos organizaciones pueden colaborar en canales y llamadas compartidos manteniendo cada una la soberanía total sobre sus propios datos, políticas de seguridad y control administrativo.

Cómo funciona la federación

La federación en Mandraki es una relación bilateral basada en consentimiento entre dos organizaciones. Ninguna parte puede imponer la federación a la otra. El proceso comienza cuando una organización envía una solicitud de federación a otra.

La solicitud especifica qué capacidades de colaboración desea habilitar la organización solicitante: mensajería, llamadas, compartición de archivos y canales compartidos. La organización destinataria revisa la solicitud y puede aprobarla con su propio conjunto de permisos. Ambas partes deben estar de acuerdo, y cualquiera puede modificar o revocar la relación en cualquier momento.

Una vez establecida una relación de federación, los usuarios de ambas organizaciones pueden participar en canales y llamadas compartidos. La experiencia es fluida: un canal compartido aparece junto a los canales internos de la organización, y los usuarios de la organización federada se identifican claramente con una insignia “Externo”.

Propiedad de los datos en canales compartidos

Un canal compartido en Mandraki tiene una única organización propietaria. Las políticas de la organización propietaria rigen la configuración de cifrado, las políticas de retención y la disponibilidad de funcionalidades de IA del canal. Las demás organizaciones participan en el canal pero no controlan su configuración.

Críticamente, cada mensaje de un canal compartido lleva un originOrgId que identifica a qué organización pertenece el remitente. Esto garantiza la trazabilidad: cada organización puede ver qué mensajes proceden de sus miembros y cuáles provienen de participantes externos.

A efectos de cumplimiento, cada organización conserva el acceso a los mensajes enviados por sus propios miembros. Si una organización abandona una federación, conserva sus propios mensajes mientras pierde acceso a los mensajes de la otra organización. La propiedad de los datos sigue el límite de la organización, no el del canal.

Gobernanza y controles de política

La federación en Mandraki se rige por controles de política granulares a nivel de organización.

Política cross-org. Los administradores establecen la postura de federación de la organización: deshabilitada (sin federación permitida), solo federada (federación únicamente con organizaciones aprobadas) o abierta (solicitudes de federación aceptadas por defecto, sujetas a aprobación individual).

Lista de permitidos. Las organizaciones pueden mantener una lista explícita de socios de federación aprobados. Solo las organizaciones de la lista pueden establecer relaciones de federación.

Requisito de aprobación. Cuando está habilitado, todas las solicitudes de federación requieren aprobación explícita del administrador, incluso si la organización solicitante figura en la lista de permitidos.

Permisos por funcionalidad. Las relaciones de federación tienen interruptores granulares de funcionalidad. Una organización puede permitir la mensajería con un socio pero no la compartición de archivos, o permitir llamadas pero no canales compartidos. Estos permisos se pueden ajustar en cualquier momento.

Estos controles reflejan la realidad de que distintas organizaciones tienen distintos apetitos de riesgo y requisitos regulatorios. Una entidad financiera podría federarse con su auditor solo para mensajería, sin compartición de archivos. Un departamento gubernamental podría federarse con un organismo sectorial para canales compartidos pero exigir aprobación para cada nuevo participante.

Límites de seguridad

La federación no fusiona los dominios de seguridad de dos organizaciones. Cada organización mantiene sus propias claves de cifrado, su propia gestión de usuarios, sus propios controles de acceso y sus propios registros de auditoría. El SFU y el servidor de API hacen cumplir los límites organizativos en cada capa.

Cuando se envía un mensaje en un canal compartido, se cifra con el contexto de cifrado del canal (que pertenece a la organización propietaria). Los usuarios de organizaciones federadas a los que se ha concedido acceso pueden descifrar y leer el mensaje. Pero la relación de federación no concede acceso a ningún otro dato dentro de la organización propietaria: los canales internos, los mensajes directos o la configuración organizativa permanecen completamente aislados.

Para las llamadas en contextos federados se aplica el mismo principio. Los participantes de ambas organizaciones se unen a la llamada a través del flujo estándar de señalización WebRTC, autenticados frente a sus respectivas organizaciones. El SFU enruta los medios entre los participantes con independencia de a qué organización pertenezcan, pero la API exige que solo se unan los participantes con permisos de federación válidos.

Identidad de instalación y federación entre instalaciones

El modelo de federación de Mandraki se extiende más allá de las organizaciones dentro de una única instalación para dar soporte a la comunicación entre despliegues separados de Mandraki: lo que llamamos federación entre instalaciones.

Cada instalación de Mandraki tiene una identidad única, que incluye un par de claves Ed25519 para autenticación criptográfica. Las instalaciones publican un descriptor well-known en /.well-known/eurocom-server que incluye su clave pública, capacidades y versión.

Cuando dos instalaciones se comunican, todas las cargas útiles se firman con la clave privada de la instalación emisora y se verifican con la clave pública de la instalación receptora. Esto evita la suplantación y garantiza que los mensajes de federación son auténticos.

La federación entre instalaciones es particularmente relevante para organizaciones con requisitos de residencia de datos. Una instalación de Mandraki en Alemania puede federarse con una instalación en Francia, permitiendo la colaboración transfronteriza mientras cada instalación mantiene la residencia de datos dentro de su respectiva jurisdicción.

La experiencia de usuario externo

Hemos prestado especial atención a cómo aparecen los usuarios federados en la interfaz. Los usuarios externos siempre se distinguen visualmente con una insignia clara “Externo”. Esto no es opcional ni configurable: la plataforma lo impone para evitar confusión sobre quién está en una conversación.

Al redactar un mensaje en un canal compartido, el área de composición recuerda al usuario que los participantes externos pueden ver sus mensajes. Al iniciar una llamada en un contexto federado, los participantes ven una indicación clara de qué organizaciones están representadas.

Estas decisiones de diseño reflejan un principio: la federación debe facilitar la colaboración entre organizaciones, pero nunca hacerla invisible. Los usuarios siempre deben saber cuándo se están comunicando a través de los límites organizativos.

El caso a favor de la federación frente a las cuentas de invitado

Muchas plataformas de colaboración abordan la comunicación entre organizaciones mediante cuentas de invitado: los usuarios externos reciben cuentas limitadas dentro del espacio de trabajo de la organización anfitriona. Este enfoque tiene varios inconvenientes que la federación evita.

Las cuentas de invitado generan carga administrativa: alguien debe crear, gestionar y, llegado el caso, desactivar cada invitado. Las cuentas de invitado difuminan los límites de seguridad: el invitado existe dentro del dominio de seguridad del anfitrión, que puede no estar alineado con las políticas de seguridad de la propia organización del invitado. Las cuentas de invitado fragmentan la comunicación: el invitado debe mantener identidades y contextos separados para cada organización con la que colabora.

La federación mantiene a cada usuario dentro del dominio de su propia organización. Se autentican con sus propias credenciales, ven los canales de su propia organización junto a los compartidos y se rigen por las políticas de su propia organización. Sin cuentas de invitado que gestionar, sin límites difusos, sin identidad fragmentada.

Para las organizaciones europeas que necesitan colaborar a través de las fronteras manteniendo la soberanía, la federación es la arquitectura que hace posible todo ello sin concesiones.