Presentamos el plugin Enterprise de Simmetric Chat
SSO con SAML 2.0 y OIDC, aprovisionamiento SCIM, registro de auditoría inmutable, white-label, copias de seguridad cifradas y licencias air-gap para equipos regulados.
Enterprise es un plugin, no un fork
La forma más común en que los proyectos de código abierto entregan un nivel enterprise es un fork: una rama privada que se aleja del código base comunitario hasta que la actualización se convierte en un proyecto de migración. Simmetric Chat eligió el otro camino. El nivel enterprise se entrega como un paquete de plugin opcional - @simmetric-chat/enterprise - cargado por el servidor comunitario en el arranque mediante un cargador de plugins. El servidor comunitario sondea el paquete al inicio:
- Encontrado y válido → el plugin registra sus rutas y las funciones enterprise se activan.
- No instalado → una línea de log a nivel info anota la build comunitaria y el servidor continúa sin cambios.
- Encontrado pero roto → el servidor sale con estrépito. Una instalación enterprise rota nunca degrada silenciosamente a comunidad - un stack SSO a medias es peor que ninguno.
La misma licencia gobierna el nivel. El código base comunitario es AGPL-3.0; el plugin enterprise es un paquete comercial con licencia separada, y un JWT de licencia (LICENSE_KEY) es lo que desbloquea las funciones. Sin una licencia válida, las rutas enterprise aún se montan, pero cada función con gating responde 402 con un payload JSON explícito que nombra la función y el nivel - tu código de integración puede ramificarse según el estado de la licencia en lugar de adivinar.
Identidad: SSO y SCIM listos para usar
El inicio de sesión único soporta los dos protocolos que las empresas realmente ejecutan: SAML 2.0 (con login, callback y endpoints de metadatos para flujos iniciados por el IdP) y OIDC (login y callback para el flujo de redirección del navegador, construido sobre una biblioteca cliente de OpenID Connect actual). Ambos se vinculan al mismo panel SSO configurable por el admin.
La configuración es flexible donde importa. OIDC puede configurarse enteramente desde el panel SSO de administración (almacenado cifrado en reposo en la base de datos), enteramente desde variables de entorno, o desde ambos - env tiene precedencia cuando está definida, así los despliegues infrastructure-as-code pueden fijar los ajustes del proveedor mientras el panel sigue siendo la fuente de verdad en los demás casos. Los proveedores integrados cubren Google, GitHub y Microsoft Entra, y un proveedor genérico acepta cualquier documento de descubrimiento.
SCIM 2.0 cierra el bucle del ciclo de vida: aprovisionamiento de usuarios y grupos a través del protocolo SCIM estándar con un endpoint protegido por token Bearer. Cuando RRHH desactiva a un usuario en tu proveedor de identidad, su cuenta de Simmetric Chat se desactiva a través del mismo flujo - sin cuentas huérfanas, sin desaprovisionamiento dirigido por hojas de cálculo. Juntos, SSO y SCIM significan que tu IdP sigue siendo la única autoridad sobre quién existe y quién puede iniciar sesión.
El registro de auditoría que no puede reescribirse
Los registros de auditoría tienen una propiedad incómoda: cuanto más valiosos son, más valioso es modificarlos. El registro de auditoría enterprise de Simmetric Chat impone la inmutabilidad a nivel de base de datos, no a nivel de aplicación.
Un rol Postgres dedicado - simmetric_audit_writer - posee solo un privilegio INSERT en la tabla de auditoría. El plugin enterprise escribe eventos de auditoría a través de un pool de conexiones separado que se autentica como ese rol, así UPDATE y DELETE fallan a nivel de base de datos, no por convención de la aplicación. Los lectores toman un camino deliberadamente separado a través de la conexión estándar de la aplicación, que tiene SELECT pero es un rol completamente diferente - el escritor no puede leer, y el lector no puede escribir.
La garantía es honesta sobre su propia configuración: cuando se define la contraseña del escritor, el log de arranque confirma que la garantía de inmutabilidad está activa; cuando falta, el registro de auditoría sigue registrando eventos pero un aviso de arranque indica que la inmutabilidad a nivel de base no se aplica. Valores por defecto a prueba de fallos más un log de arranque veraz - el patrón que esta plataforma usa en todas partes.
El registro de auditoría se expone a los admins a través de un visor de registro de eventos, con gating por una bandera de licencia audit_log_immutable. Eventos de autenticación, operaciones de documentos, cambios de configuración, elusiones DLP, cambios de retención - la pista es la respuesta a "¿qué pasó realmente?", y compone con la historia RBAC comunitaria: el acceso al registro en sí es una permisión.
White-label y copias de seguridad cifradas
Dos funciones apuntan a equipos que entregan Simmetric Chat a sus propios clientes o lo ejecutan como infraestructura interna con políticas de datos estrictas:
El white-label elimina el chrome del producto de las superficies orientadas al cliente - el widget incrustado, los valores por defecto de branding, la personalización a nivel de UI - bajo una bandera de licencia dedicada. Una consultoría que despliega un asistente de conocimiento para un cliente puede presentar el asistente como propio del cliente; la plataforma permanece en segundo plano.
Las copias de seguridad van más allá de los volcados de base de datos: los trabajos programados y bajo demanda producen archivos de copia de seguridad cifrados, las políticas de retención deciden qué conservar y durante cuánto tiempo, y una división de permisos separa quién puede configurar un destino, quién puede ejecutar un trabajo, quién puede inspeccionar logs y quién puede restaurar. Esa última distinción importa - disparar una copia de seguridad y restaurar datos de producción en un workspace arbitrario son niveles de confianza diferentes, y el modelo de permisos los trata así.
Licencias air-gap para entornos regulados
Los entornos que necesitan SSO, auditoría inmutable y copias de seguridad controladas suelen ser los mismos entornos sin acceso a internet. La licencia enterprise está construida para eso: la licencia es un JWT firmado con RS256 cuya clave pública incrustada viaja con el servidor comunitario. La verificación ocurre localmente - el servidor comprueba la firma contra la clave incrustada, así ningún servidor de licencias necesita ser alcanzable. Define LICENSE_KEY en el entorno del servidor, reinicia, y las funciones se desbloquean; retírala, y se cierran de vuelta a comunidad con respuestas 402 explícitas.
Ese diseño significa que un despliegue enterprise corre enteramente dentro de un centro de datos: LLM locales mediante Ollama, almacenes vectoriales locales, embeddings locales, OCR local y ahora validación de licencia local. El air-gap no es un modo degradado atornillado después - es la forma de despliegue en torno a la cual se diseñó este producto.
Qué significa esto para la línea v0.22
Las líneas comunitaria y enterprise avanzan juntas. El servidor comunitario declara el plugin enterprise como una dependencia par opcional; el cargador lo resuelve en el arranque y el contexto compartido del plugin inyecta las preocupaciones centrales (auth, crypto, base de datos, logger) para que el plugin solo pueda depender del contrato compartido, nunca de los internals comunitarios. Los lanzamientos comunitarios y enterprise se construyen contra la misma versión compartida, y un desajuste de versión falla con estrépito en el arranque en lugar de comportarse mal en runtime.
Para los operadores, el resumen práctico: instala el paquete del plugin, define un LICENSE_KEY válido, configura SSO en el panel de administración, define la contraseña del escritor de auditoría y reinicia. El log de arranque te dice exactamente cuáles de esos pasos tuvieron éxito. El nivel comunitario sigue siendo AGPL-3.0 y completamente funcional - SSO, auditoría y copias de seguridad son aditivos por encima, con gating por licencia en lugar de por un fork de código.


