Warpgate SSO integration
Nel post precedente su Warpgate abbiamo visto come configurare l’autenticazione a 2 fattori per l’accesso SSH ai server. Qui andiamo invece ad analizzare la possibilità di integrare sul sistema l’autenticazione Single Sign-On. Uno degli aspetti più interessanti di Warpgate è la possibilità di integrare l’autenticazione Single Sign-On con provider enterprise come Microsoft Entra ID (Azure AD). Grazie al supporto per protocolli standard come OpenID Connect (OIDC) e SAML 2.0, Warpgate può delegare completamente il processo di autenticazione al sistema di identity management aziendale, consentendo agli utenti di accedere utilizzando le stesse credenziali Microsoft già adottate per gli altri servizi corporate.
Questo approccio da un lato semplifica l’esperienza utente, eliminando la necessità di gestire account locali separati; dall’altro consente di applicare automaticamente tutte le policy di sicurezza definite in Azure, come Multi-Factor Authentication, Conditional Access, controllo dei dispositivi compliant e restrizioni geografiche. In pratica, Warpgate diventa il punto di accesso unificato alle infrastrutture tecniche, mentre Azure mantiene il ruolo di autorità centrale per identità e sicurezza.
Warpgate MFA tramite TOTP
Warpgate è una soluzione open source di accesso sicuro con funzioni di bastion host per server SSH, database, Kubernetes e servizi web, centralizzando autenticazione, autorizzazioni e auditing. Non è jump host, ma si comporta come un gateway intermedio tra utenti e infrastruttura interna: autentica gli utenti tramite SSO/MFA, applica policy di accesso granulari, registra le sessioni e inoltra le connessioni verso le risorse autorizzate senza esporre direttamente la rete interna o richiedere connessioni VPN. In poche parole, è un’ottima soluzione per concedere accesso a risorse che non sono esposte direttamente su Internet.
Per tutti i dettagli di installazione e configurazione iniziale vi rimando alla documentazione ufficiale di warpgate, qui invece vedremo come attivare l’autenticazione MFA tramite OTP per connessioni SSH.
Kamailio e RTPEngine, un SBC Open Source
Un SBC (Session Border Controller) SIP permette di separare il traffico VoIP esterno alla nostra subnet dal traffico generato all’interno della subnet stessa, assicurando i corretti flussi di segnalazione e media tra esterno ed interno e viceversa. Il termine “Border” infatti, sta proprio ad indicare questa funzione, dato che un SBC si trova ai bordi della rete e rappresenta il confine tra una network interna ed Internet. Supponiamo ad esempio di avere un telefono VoIP (che usa il protocollo SIP) all’interno di una LAN e che tale telefono debba ricevere chiamate da un VoIP Provider pubblico, che necessariamente si troverà su Internet. Per poter comunicare direttamente, il telefono dovrebbe avere un IP pubblico e questo rappresenterebbe un problema dal punto di vista della sicurezza della nostra rete. L’alternativa si chiama SBC, che posto tra la LAN e Internet disaccoppia il leg di chiamata pubblico dal Provider alla sua interfaccia pubblica, dal leg di chiamata privato tra la sua interfaccia privata e gli elementi interni alla LAN.
Kamailio permission module
Il modulo permission rende disponibili una serie di funzionalità e controlli per implementare ACL basate su IP sorgente, From, Request Uri. Questo ci permette di controllare chi può fare cosa, ad esempio se richieste che arrivano da un certo IP sorgente possono essere ruotate a destinazione, oppure se una certa SIP Uri può essere gestita o deve essere rifiutata.
Kamailio SecureSIP gateway con rtpengine
Nei post precedenti abbiamo già parlato di rtpengine e di come usarlo con Kamailio per gestire il NAT o la transcodifica audio. In questo articolo invece vediamo come utilizzare Kamailio con il modulo TLS e rtpengine per realizzare un TLS/SRTP proxy, che sul primo leg di chiamata utilizza il SIP sicuro con TLS e SRTP e sul secondo leg utilizza UDP e RTP. In questo modo avremo la possibilità di aggiungere il supporto del Secure SIP anche a media server che supportano il solo trasporto UDP con RTP in chiaro e renderli quindi sicuri. Il protocollo SRTP (Secure RTP) è utilizzato con SIP su TLS e trasporta la voce in pacchetti IP crittografati, in modo da non permettere l’intercettazione e la decodifica dei pacchetti audio.
Kamailio TLS module
Il modulo “tls” è pensato appositamente per aggiungere il supporto di TLS (Transport Layer Security) a livello di trasporto TCP e permettere di gestire traffico che fa uso di SIPS (SIP Secure), cioè traffico SIP criptato. Tutti i dettagli sono disponibili sulla documentazione ufficiale di Kamailio relativa al modulo tls. Qui vedremo brevemente come attivarlo sulla nostra installazione di Kamailio.
Genesys Cloud integrazione con ChatBot esterno
Con l’introduzione in Genesys Cloud delle WebChat APIs è possibile integrare un proprio ChatBot esterno con la piattaforma Genesys offrendo un’interessante user experience per gli utenti. Sfruttando le WebChat APIs si può ad esempio sviluppare un proprio ChatBot che accoglie gli utenti con la possibilità di switching tra ChatBot e Agente reale su Genesys Cloud, rendendo anche disponibile all’agente l’history della conversazione che l’utente ha avuto con il BOT prima di essere trasferito.
Genesys Cloud integrazione SIP con IVR esterno, trasferire indietro la chiamata
Nell’articolo precedente abbiamo configurato un BYOC SIP Trunk su Genesys Cloud e trasferito una chiamata da un flusso Genesys ad un IVR esterno. Qui vedremo invece come far ritornare la chiamata sul flusso Genesys dopo averla gestita sull’IVR esterno.
Quindi ricapitolando, abbiamo un utente che viene accolto su un flusso vocale Architect in Genesys Cloud, l’utente viene poi trasferito via SIP ad un IVR esterno dal quale è possibile farlo rientrare in Genesys Cloud, sullo stesso flusso o su un qualsiasi altro flusso.
Genesys Cloud integrazione SIP con IVR esterno
In questi giorni mi è capitato di giocare un po’ con la piattaforma Genesys Cloud ed ho deciso di scrivere un paio di articoli sugli aspetti di integrazione con sistemi esterni, in particolare sulla possibilità di trasferire una chiamata ad un IVR esterno per poi farla rientrare sul flusso Genesys, e sulla possibilità di trasferire ad una coda chat un utente precedentemente accolto su un chatbot esterno. Qui vedremo come gestire il primo caso, quindi trasferire una chiamata da un flusso Genesys ad un IVR esterno.
Bilanciare il traffico verso Galera Cluster con HAProxy
Abbiamo già visto qui le caratteristiche di Galera Cluster, che permette di realizzare una topologia multi-master active-active di database con replica sincrona dei dati, abilitando le operazioni di lettura e scrittura su tutti i nodi del cluster.