Presentazione del plugin Enterprise di Simmetric Chat

Enterprise è un plugin, non un fork

Il modo più comune in cui i progetti open-source distribuiscono un tier enterprise è il fork: un ramo privato che diverge dal codebase comunitario finché l'aggiornamento diventa un progetto di migrazione. Simmetric Chat ha scelto l'altra strada. Il tier enterprise arriva come pacchetto plugin opzionale - @simmetric-chat/enterprise - caricato dal server comunitario all'avvio tramite un plugin loader. Il server comunitario cerca il pacchetto all'avvio:

• Trovato e valido → il plugin registra le proprie rotte e le funzionalità enterprise vanno in vita.
• Non installato → una riga di log a livello informativo segnala la build comunitaria e il server continua senza cambiamenti.
• Trovato ma rotto → il server esce in modo sonoro. Un'installazione enterprise rotta non degrada mai silenziosamente a community - uno stack SSO a metà funzionante è peggiore di nessuno.

Lo stesso licenziamento governa il tier. Il codebase comunitario è AGPL-3.0; il plugin enterprise è un pacchetto commerciale con licenza separata, e un JWT di licenza (LICENSE_KEY) è ciò che sblocca le funzionalità. Senza una licenza valida le rotte enterprise si montano comunque, ma ogni funzionalità vincolata risponde 402 con un payload JSON esplicito che nomina la funzionalità e il tier - il vostro codice di integrazione può diramarsi sullo stato della licenza anziché tirare a indovinare.

Identità: SSO e SCIM pronti all'uso

Il single sign-on supporta i due protocolli che le imprese realmente usano: SAML 2.0 (con endpoint di login, callback e metadata per i flussi avviati dall'IdP) e OIDC (login e callback per il flusso di reindirizzamento del browser, costruito su una libreria client OpenID Connect aggiornata). Entrambi si agganciano allo stesso pannello SSO configurabile dall'amministrazione.

La configurazione è flessibile dove conta. OIDC può essere configurato interamente dal pannello SSO admin (conservato cifrato a riposo nel database), interamente da variabili d'ambiente, o da entrambi - l'ambiente ha la precedenza quando impostato, così che i deployment infrastructure-as-code possano fissare le impostazioni del provider lasciando il pannello come fonte di verità altrimenti. I provider predefiniti coprono Google, GitHub e Microsoft Entra, e un provider generico accetta qualsiasi documento di discovery.

SCIM 2.0 chiude il ciclo di vita: provisioning di utenti e gruppi tramite il protocollo SCIM standard con un endpoint protetto da token Bearer. Quando le risorse umane disattivano un utente nel vostro identity provider, il suo account Simmetric Chat si disattiva attraverso lo stesso flusso - nessun account orfano, nessun deprovisioning guidato da fogli di calcolo. Insieme, SSO e SCIM significano che il vostro IdP resta l'unica autorità su chi esiste e chi può accedere.

Il log di audit che non può essere riscritto

I log di audit hanno una proprietà scomoda: più sono preziosi, più sono preziosi da modificare. Il log di audit enterprise di Simmetric Chat impone l'immutabilità al livello del database, non al livello applicativo.

Un ruolo Postgres dedicato - simmetric_audit_writer - detiene solo il privilegio INSERT sulla tabella di audit. Il plugin enterprise scrive gli eventi di audit attraverso un pool di connessioni separato che si autentica con quel ruolo, così che UPDATE e DELETE falliscano al livello del database, non per convenzione applicativa. I lettori seguono deliberatamente un percorso separato attraverso la connessione applicativa standard, che ha SELECT ma è un ruolo del tutto diverso - lo scrittore non può leggere, e il lettore non può scrivere.

La garanzia è onesta riguardo alla propria configurazione: quando la password dello scrittore è impostata, il log di avvio conferma che la garanzia di immutabilità è attiva; quando manca, il log di audit registra comunque gli eventi ma un avviso di avvio dichiara che l'immutabilità a livello di database non è imposta. Default a prova di errore più un log di avvio veritiero - il pattern che questa piattaforma usa ovunque.

Il log di audit è esposto agli admin attraverso un visualizzatore del log eventi, vincolato da un flag di licenza audit_log_immutable. Eventi di autenticazione, operazioni sui documenti, modifiche alle impostazioni, bypass DLP, cambi di retention - la traccia è la risposta a "cosa è effettivamente successo", e si compone con la storia RBAC comunitaria: l'accesso al log stesso è un permesso.

White-label e backup cifrati

Due funzionalità si rivolgono ai team che consegnano Simmetric Chat ai propri clienti o lo eseguono come infrastruttura interna con politiche severe sui dati:

Il white-labeling rimuove l'abbigliamento del prodotto dalle superfici rivolte ai clienti - il widget incorporato, i default del branding, la personalizzazione a livello di interfaccia - sotto un flag di licenza dedicato. Una consulenza che distribuisce un assistente della conoscenza per un cliente può presentare l'assistente come cosa del cliente; la piattaforma resta sullo sfondo.

I backup vanno oltre i dump del database: job schedulati e on-demand producono archivi di backup cifrati, le politiche di retention decidono cosa conservare e per quanto, e una suddivisione dei permessi separa chi può configurare una destinazione, chi può eseguire un job, chi può ispezionare i log e chi può ripristinare. Quell'ultima distinzione conta - avviare un backup e ripristinare dati di produzione in un workspace arbitrario sono livelli di fiducia diversi, e il modello di permessi li tratta così.

Licenze air-gap per gli ambienti regolamentati

Gli ambienti che necessitano di SSO, audit immutabile e backup controllati sono frequentemente gli stessi ambienti senza accesso a Internet. Il licenziamento enterprise è costruito per questo: la licenza è un JWT firmato RS256 la cui chiave pubblica incorporata viaggia con il server comunitario. La verifica avviene localmente - il server controlla la firma contro la chiave incorporata, così che nessun server di licenze debba essere raggiungibile. Impostate LICENSE_KEY nell'ambiente del server, riavviate e le funzionalità si sbloccano; rimuovetela, e si richiudono a community con esplicite risposte 402.

Questo design significa che un deployment enterprise gira interamente dentro un data center: LLM locali tramite Ollama, vector store locali, embedding locali, OCR locale e ora anche validazione della licenza locale. L'air-gap non è una modalità degradata aggiunta dopo - è la forma di deployment attorno alla quale questo prodotto è stato progettato.

Cosa significa per la linea v0.22

Le linee comunitaria ed enterprise si muovono insieme. Il server comunitario dichiara il plugin enterprise come peer dependency opzionale; il loader lo risolve all'avvio e il contesto plugin condiviso inietta le problematiche centrali (autenticazione, crittografia, database, logger) così che il plugin possa dipendere solo dal contratto condiviso, mai dagli interni comunitari. I rilasci comunitari ed enterprise sono compilati contro la stessa versione condivisa, e un disallineamento di versione fallisce sonoramente all'avvio anziché comportarsi male a runtime.

Per gli operatori, il riepilogo pratico: installate il pacchetto plugin, impostate un LICENSE_KEY valido, configurate SSO nel pannello di amministrazione, impostate la password dello scrittore di audit e riavviate. Il log di avvio vi dice esattamente quali di quei passaggi sono riusciti. Il tier comunitario resta AGPL-3.0 e pienamente funzionante - SSO, audit e backup sono additivi sopra di esso, vincolati dalla licenza anziché da un fork del codice.

Leggi la guida completa nella documentazione →