Configurazione di Oplon Secure Access
In questa parte di guida, rivolta agli amministratori della suite Oplon, descriviamo i concetti fondamentali di Oplon Secure Access e come configurare nuove risorse per consentirne l’accesso da terzi.
Al termine della guida si comprenderanno i concetti di User Group e Resource e si riuscirà a creare per la prima
volta una risorsa di tipo Host o Web App/Link.
Prerequisiti
- Avere già installato e configurato l’appliance come descritto qui.
- Avere configurato MFA come indicato in questa guida.
- (Opzionale) Se si desidera usare il File Managing su risorse Windows, installare OpenSSH Server su ogni risorsa:
- Guida Microsoft per Windows ≥ 10 e Windows Server ≥ 2019
- Guida Win32-OpenSSH per versioni precedenti
Concetti fondamentali
Dentro OSA esistono alcuni concetti fondamentali che è utile spiegare:
User Group
Gli User Group rappresentano una classe di utenti con gli stessi privilegi e servono per associare risorse (Host / Link) agli utenti.
Uno User Group ha un nome univoco e una descrizione. Gli User Group definiti in Oplon Secure Access si associano
agli User Group definiti in MFA—come descritto in questa guida—in modo che a ogni utente censito in Oplon MFA venga concesso il privilegio corretto.
Resources e Location
In Secure Access una Resource è un’entità che può identificare:
- un Host (Windows, Linux, macOS)
- una Remote App
- una Web App/Link
Ogni risorsa può essere catalogata tramite una Location, un’etichetta usata per raggruppare logicamente le risorse.
Host
Un Host è la rappresentazione di una macchina (fisica o virtuale) identificata da IP/hostname. È possibile assegnare a un Host una Location per raggruppamento logico.
Su un Host possono convivere vari tipi di accesso:
- SSH
- RDP
- Remote App (RDP)
- VNC
- SFTP (File manager)
Questi accessi possono essere assegnati ai User Group secondo le policy desiderate. È inoltre possibile definire dei OS login/AD login predefiniti, in modo che l’utente non debba inserire né username né password.
Remote App
Le Remote App (RDP only) sono entità figlie di un Host e consentono di esporre singole applicazioni tramite il protocollo RDP.
Web App/Link
Una Web App/Link è una risorsa rappresentata da un URL. Può essere accessibile tramite Oplon Secure Access:
- in modalità nativa HTTP/HTTPS
- tramite il Reverse Proxy di Oplon (con autenticazione MFA)
- pubblicata su Internet
- in modalità Browser Isolation (vedi qui)
La modalità nativa richiede meno risorse rispetto alla Browser Isolation, che necessita di appliance dedicate ma offre un livello di sicurezza e segregazione superiore.
Shared Folders
Le Shared Folders permettono di montare, tramite l’Oplon Client (Windows, Linux, macOS), dei drive di rete protetti dalla piattaforma (MFA, ZTNA, policy).
L’accesso è sempre autenticato e autorizzato in base agli User Group e alle policy configurate.
Attualmente il protocollo supportato per il mount è WebDAV: la condivisione viene esposta al client come unità/drive o mount point e tutte le operazioni file sono mediate e tracciate da Oplon.
Trusted Connection
Una Trusted Connection apre un canale sicuro tra l’host e i backend selezionati (ad es. DB Server, Telenet, applicativi in generale).
L’accesso passa tramite MFA, ZTNA e le policy PAM di Oplon; l’Oplon Client può localmente reverse‑proxare il servizio su localhost
in una porta specifica (es. localhost:NNNN), consentendo l’utilizzo di servizi interni senza esporre porte pubbliche.
Interfaccia di configurazione
Per configurare nuove risorse aprire l’interfaccia di amministrazione di Oplon Secure Access all’indirizzo:
https://<your-ip>:4444 e autenticarsi.
Nel menu di sinistra aprire Secure Access > Settings e accedere al modulo.

In questa schermata è possibile:
- visualizzare la lista degli
User Group - gestire la lista degli
Host - gestire la lista delle Web App/Link
Aggiunta nuovi User Groups
Per aggiungere un nuovo User Group cliccare il pulsante verde (+) su uno User Group esistente: ne verrà creato uno vuoto e poi potrà essere modificato.
Per ogni User Group è possibile abilitare o disabilitare il permesso di utilizzare le session temporary connections (funzionalità riservata tipicamente agli amministratori) e la registrazione video delle sessioni ad esse associate.
Le session temporary connections sono connessioni temporanee che consentono agli utenti — appartenenti ad almeno un gruppo in cui questa funzionalità è abilitata — di connettersi a qualsiasi Host, anche in assenza di gruppi associati alla risorsa di destinazione.
Gli utenti con questo privilegio possono accedere a una risorsa anche senza possedere gruppi ad essa associati, a condizione che siano in possesso delle relative credenziali di accesso.

Aggiungere un nuovo Host
Per aggiungere un nuovo Host cliccare il pulsante verde (+) di un Host esistente: verrà duplicato e poi potrà essere modificato.
Per modificare un Host è consigliabile aprire i dettagli premendo See Details.
Campi importanti:
Hostname/IPNameLocationDescription- Servizi e porte:
SSH,RDP,VNC,SFTP(File manager)… - Eventuali
RD Gateway(RDP only) User Groupassociati- Eventuali
Remote App(RDP only)

Qui abbiamo configurato un Host
127.0.0.1e associato loUser GroupLocal.
Aggiungere una nuova Remote App
Per aggiungere una nuova Remote App, bisogna necessariamente partire da un Host con l’accesso RDP già configurato.
Per aggiungere una Remote App partire da un Host con accesso RDP configurato, aprire Secure Access > Settings aprire un Host e poi su una Applications possiamo inserire:
name(nome visualizzato)descriptionapp name(alias RDP)working dir(opzionale) la directory di lavoro dell’appargs(opzionale) gli argomenti di start dell’app

Ricordarsi di eseguire sempre Save e Re‑Init.
Aggiungere una nuova Web App
Per aggiungere una nuova Web App, è possibile andare sempre nell’interfaccia di Settings e infondo trovare la schermata Web Apps.
Qui inserire le informazioni minime per poter usufruire della Web App ovvero:
nameurllocation

Ricordarsi di eseguire Save e Re‑Init.
Browser Isolation
Se per la Web App nativa è necessario seguire le istruzioni indicate sopra, per rendere disponibile la Web App in modalità Browser Isolation è necessario attivare l’opzione enable Browser Isolation.
Da qui, entrando dentro con la freccetta nera a fine rigo, possono seguirsi una serie di configuzioni/personalizzazioni specifiche per la sola modalità di Browser Isolation e sono:

- enable Browser Isolation: serve ad abilitare la browser isolation
- Whitelisted: serve ad andare in white list sull’url inserito sopra. Questo avrà l’effetto di bloccare la navigazione su tutti gli altri url se non l’url stesso ed eventualmente quelli specificati sotto in “White Listed Domain”:
- White Listed Domains: Qui è possibile indicare una serie di indirizzi da non bloccare, se si è in “Whitelisted=true”, separati da virgola.
La sintassi da seguire è:
<scheme>://<host><path>(qui per una guida più completa sulla sintassi)
Nel caso della whitelist, attualmente non possono essere impostate le porte nello schema.
Aggiungere una nuova Shared Folder
Per aggiungere una Shared Folder basta cliccare (+) sulla schermata dedicata.
Per modificare una Shared Folder è consigliato entrare nel dettaglio tramite il pulsante “See Details”.
Campi configurabili:
url: indirizzo tramite l’ADC di Oplon (es.https://sales.drive.acme.net)name: nome leggibileassignedUserGroups:User Groupautorizzatidescription: breve descrizione e policy

Configurazione Shared Folders su Oplon ADC
Prima di tutto, è importante verificare che l’endpoint /api/sf/verify-token del grouping di Secure Access sia presente e abilitato con la seguente regola di rewrite applicata: LBLWebDavConnector.
Se l’endpoint non è presente (caso in cui si viene da un’installazione precedente alla 11.3.0), è necessario crearlo clonando l’endpoint /api e personalizzandolo con i valori richiesti.

Perché l’url funzioni, l’ADC di Oplon deve eseguire il reverse‑proxy verso il backend WebDAV e applicare la rewrite rule LBLWebdavConnector.
Passi minimi:
- creare/usare il virtual domain (es.
https://sales.drive.acme.net) - applicare la rewrite rule
LBLWebdavConnectorsulla route
Assicurarsi di fornire un certificato SSL/TLS valido per il dominio reverse‑proxato (ad esempio sales.drive.acme.net). Un certificato corretto evita avvisi del browser e garantisce connessioni sicure tra i client e l’ADC.
Se si usa MFA sullo stesso listener o grouping, occorrerà impostare la regola di rewrite di MFA in NOP (come riportato nello screenshot).

Firewalling dei file trasferiti con Shared Folders
Per filtrare i file WebDAV applicare due rewrite rule sulla stessa route:
LBLHTTPWebDavFileCheckHeader(rewrite header)LBLHTTPWebDavFileCheckBody(rewrite body)
Entrambe le rule sono personalizzabili: modificando la variable WHITE_LIST_EXT si imposta la lista di estensioni consentite / bloccate (es. .exe,.bat,.js).
Le rule verificheranno header e/o contenuto dei trasferimenti e bloccheranno i file non consentiti.

Aggiungere una nuova Trusted Connection
Per aggiungere una Trusted Connection cliccare (+) nella sezione Trusted Connections; la voce duplicata è poi modificabile.
Campi configurabili:
name: nome descrittivo della connessionedescription: breve descrizioneendpoint IP: IP del backend di destinazioneendpoint PORT: porta del backend di destinazionelistener IP: IP su cui Oplon ascolta le connessioni per il tunnelinglistener PORT: porta su cui Oplon ascolta le connessioni per il tunnelinglocation: etichetta logicaconnection timeout: timeout di connessione (ms)upstream port: porta locale sulocalhostche l’Oplon Client esporrà (es.localhost:NNNN)assignedUserGroups:User Groupautorizzati
Salvare e fare Save e Re‑Init.

Configurazione di Trusted Connections su Oplon ADC
Per poter creare almeno una Trusted Connection è necessario predisporre sul modulo ADC un listener dedicato al tunneling.
- Andare in ADC Settings > Listeners e abilitare “View Template Listners”.
- Cercare il template denominato “Trusted Connections listener” e usare il pulsante Copy per copiarlo nel modulo ADC target.
- Modificare il listener appena copiato impostando l’address e la listener PORT desiderati per il tunneling.
- Nota bene: questo listener opera a Layer 4 ed ha applicata la rewrite rule:
LBLRWL4P2P. - Se il tunnel richiede terminazione o rientro SSL, associare al listener il certificato appropriato (keystore/alias) e abilitare le opzioni SSL prima del salvataggio.
- Salvare le modifiche e procedere con Save / Re‑Init del modulo ADC.

- È anche importante inoltre, abilitare (se non già fatto) i due endpoint del grouping di Secure Access che si chiamano corrispettivamente:
/api/p2pe/api/p2p/verify-token
Se gli endpoint non dovessero essere presenti (caso in cui si viene da un’installazione precedente alla 11.3.0), è necessario crearli clonando l’endpoint /api e personalizzandolo con i valori richiesti.
| Address | Port | URI Path | RW Header Rules |
|---|---|---|---|
| 127.0.0.1 | 2222 | /api/p2p | LBLP2PConnector 2faGeneric;NOP |
| 127.0.0.1 | 2222 | /api/p2p/verify-token | LBLP2PConnector |

Assicurarsi di fornire un certificato SSL/TLS valido per il dominio reverse‑proxato. Un certificato corretto evita avvisi del browser e garantisce connessioni sicure tra i client e l’ADC.
Assegnazione User Group
L’associazione di uno User Group a una risorsa conferisce il diritto di accesso agli utenti del gruppo. Assegnando una risorsa a uno User Group si abiliteranno/diseabiliteranno varie policy, tra cui:
- accesso
SSH - accesso
RDP - accesso
VNC File Manager(con opzioni: Upload, Download, Hypercopy)- copia/incolla remoto
Impersonification- logging di sessione (RDP/SSH)
- stampante virtuale, audio in/uscita

Se non è definito almeno un OS Login/AD Login su una risorsa assegnata a un User Group, gli utenti di quel gruppo potranno autenticarsi con qualsiasi credenziale a prompt.
Assegnazione di uno User Group con Impersonification
L’Impersonification consente di mappare l’identità digitale dell’utente (proveniente da MFA e/o Active Directory) a uno specifico OS Login/AD Login (es. utenza di dominio o locale) per l’accesso alle risorse.
L’impersonification può provenire da diverse fonti:
- MFA: definita nel MFA Manager e per riassumero può essere:
- Globale: un singolo impersonification valido ovunque (es.
ImpersonificationGlobal). - Per Gruppo: specifica per l’appartenenza a un gruppo (sintassi
Group::Impersonification).
- Globale: un singolo impersonification valido ovunque (es.
- Active Directory: derivata dall’integrazione AD (
ImpersonificationAD).
Regole di priorità:
- Possono esistere più impersonification legati ai gruppi (da MFA), ma solo uno per ogni gruppo specifico. (Questo ha priorità su quello globale)
- Può esistere un solo impersonification AD. (Questo ha priorità su quello globale)
- Può esistere un solo impersonification globale (da MFA).
Logica di Accesso (Strict vs Non-Strict)
Il controllo degli accessi varia in base a come è configurato lo User Group sulla risorsa:
-
Modalità Non-Strict (Nessun
OS Login/AD Loginspecificato nel gruppo): L’accesso è consentito. Se è presente un valore di impersonificazione (si guarda quello per gruppo se esisteGroup::Impersonification, altrimenti si passa a quello globale o di AD se esisteImpersonificationGlobal/ImpersonificationAD), verrà proposto come username per la sessione. -
Modalità Strict (Almeno un
OS Login/AD Loginspecificato nel gruppo): L’accesso è consentito solo se il valore di impersonificazione dell’utente (si guarda quello per gruppo se esisteGroup::Impersonification, altrimenti si passa a quello globale o di AD se esisteImpersonificationGlobal/ImpersonificationAD) corrisponde esattamente a uno degliOS Login/AD Loginelencati nella configurazione del gruppo.
Tabella riassuntiva assegnazione User Group
| OS/AD Login Names | Comportamento di Accesso |
|---|---|
| ❌ | Libero: L’utente inserisce qualsiasi credenziale a prompt. |
| ✅ | Vincolato: L’utente seleziona uno degli utenti definiti (password gestita dal Vault). |
Tabella riassuntiva assegnazione User Group con impersonification a true
| OS/AD Login Names | Group::Impersonification | Global/AD Impersonification | Comportamento di Accesso |
|---|---|---|---|
| ❌ (Non-Strict) | ❌ | ✅ | Impersonato: L’utente entra automaticamente con l’identità Global/AD. |
| ❌ (Non-Strict) | ✅ | ➖ | Impersonato (Gruppo): L’utente entra con l’identità del Gruppo (che ha priorità su Global). |
| ✅ (Strict) | ❌ | ✅ | Verificato: Accesso consentito solo se l’identità Global/AD è presente nella lista OS/AD Login. |
| ✅ (Strict) | ✅ | ➖ | Verificato (Gruppo): Accesso consentito solo se l’identità del Gruppo è presente nella lista OS/AD Login. |
Assegnazione OS Login/AD Login a uno User Group
Una volta assegnato uno User Group dentro un Host, possiamo assegnarli degli utenti prefissati che devono esistere all’interno dell’host stesso (OS Login) o all’interno di un dominio Active Directory (AD Login).
Entrambi, una volta popolati, andranno a contribuire alla creazione dei Vault di Secure Access, corrispettivamente avremo un:
- OS Login Vault per gli utenti locali della macchina
- AD Login Vault per gli utenti di dominio Su questa parte rimandiamo alle sezioni successive e alla pagina di configurazione dei vault.
Qui possiamo inserire tanti utenti quanti sono quelli con cui vogliamo far accedere quel determinato User Group.
L’inserimento di anche un solo utente, disabilita la possibilità per lo User Group di fare accesso con qualsiasi credenziale forzando gli accessi successivi con le sole credenziali indicate.
Inserendo anche un solo username si costringeranno gli utenti appartenenti a quello User Group di entrare unicamente con quello username e d’inserire ogni volta le password corrispettive.
Nel Caso si voglia inserire anche una password, per far si che l’utente non debba ricordarla, saperla o inserirla ogni volta, rimandiamo ai paragrafi successivi.

Inserimento password per un OS Login (Host Vault)
Per assegnare la password a un OS Login (assegnato a uno User Group) di un Host, occorre andare nella sezione Host Vault tramite il menù: PAM Management > Vault Manager > Host Vault
Cercare la risorsa corrispettiva dalla barra di ricerca e cliccare il pulsante con la chiave verde
per andare in modifica sugli OS Login Names.

Da qui selezionare gli utenti di cui si vogliono inserire le password dal menu a tendina e inserire le
corrispettive password

Ricordarsi sempre di fare Save e Re‑Init.
Inserimento password per un AD Login (AD Vault)
Per assegnare la password a un AD Login (assegnato a uno User Group) di un Host, occorre andare nella sezione AD Vault tramite il menù: PAM Management > Vault Manager > AD Vault
Cercare lo username di AD corrispettivo dalla barra di ricerca e cliccare il pulsante con la chiave verde
per andare in modifica sugli AD Login Names.

Da qui è possibile inserire la corrispettiva password:

Ricordarsi sempre di fare Save e Re‑Init.
Access Schedule
Questa funzionalità consente di controllare quando una macchina può essere raggiunta o utilizzata.
Le impostazioni vengono definite in ogni User Group assegnato alla risorsa.
I parametri dello User Group sono:
- Enable access schedule: indica se abilitare la restrizione temporale;
- Time zone: indica il time zone sul quale si applica la restrizione temporale.

Nel dettaglio dello User Group esiste un pannello chiamato Access Schedule che definisce le regole di accesso.

Parametri di configurazione
| Parametro | Tipo | Descrizione |
|---|---|---|
enable | boolean | Indica se la restrizione temporale è attiva. Se false, l’accesso è sempre consentito. |
daily | boolean | Se true il controllo è giornaliero; se false, si applica un intervallo assoluto continuo tra due istanti temporali. |
fromDate | string (YYYY-MM-DD) | Data di inizio. |
toDate | string (YYYY-MM-DD) | Data di fine. |
fromTime | string (HH-MM) | Ora di inizio. |
toTime | string (HH-MM) | Ora di fine. |
Logica di accesso
-
enable = false: nessuna restrizione, l’accesso è sempre consentito (gli altri parametri non influenzano il risultato). -
enable = trueedaily = false: Pianificazione assoluta. L’accesso è consentito solo all’interno di un intervallo continuo compreso tra:fromDate + fromTimeetoDate + toTime. Esempio:Parametro Valore fromDate2025-10-01 fromTime08:00 toDate2025-10-05 toTime19:00 Accesso valido solo dal 01/10 ore 08:00 al 05/10 ore 19:00.
-
enable = trueedaily = true: Pianificazione ricorrente giornaliera. La finestra è valida solo se:- La data corrente rientra tra
fromDateetoDate - L’orario rientra nella finestra definita da
fromTimeetoTime
Condizione Esempio Logica di accesso fromTime < toTime08:00 – 17:00 Accesso solo tra 08:00 e 17:00 dello stesso giorno fromTime > toTime22:00 – 06:00 Accesso dopo le 22:00 oppure prima delle 06:00 (attraversa la mezzanotte) - La data corrente rientra tra
Schema riepilogativo
| Enable | Daily | Tipo di intervallo | Logica di valutazione | Accesso consentito |
|---|---|---|---|---|
| false | qualsiasi | Nessuno | Nessuna restrizione | Sempre |
| true | false | Finestra assoluta | Controllo continuo | adesso ∈ [fromDate+fromTime , toDate+toTime] |
| true | true | Finestra giornaliera | Controllo ricorrente | oggi ∈ [fromDate , toDate] e ora nel range |
Parametri Trusted Connections
Nel listener Trusted Connection è possibile impostare il parametro protocol al valore trusted-connection ottenendo così un timeout client di 12 ore (quello di default è di 7 minuti e mezzo). Se la connessione rimane inattiva oltre questo limite, viene chiusa automaticamente.
Nel file di configurazione L4.conf contenuto nella cartella conf del modulo ADC (platform, standardHA o enterprise), è possibile specificare ulteriori regole.
- TRUST_CONN_TRACE=val: val può essere
trueofalse. Abilita/disabilita i log verbosi per fare debug; - TRUST_CONN_LEASE_TIME_CUT_CONN=n: n è un valore in millisecondi che rappresenta il timeout di connessione (se impostato viene preso il minimo tra il valore di protocol del listener e questo valore);
- TRUST_CONN_INTERVAL_TO_TOUCH=n: n è un valore in millisecondi che rappresenta ogni quanto far eseguire la verifica del traffico che resettare il timeout di connessione.
Network Metrics
La funzionalità di monitoraggio delle metriche, consente di analizzare in tempo reale e storicizzare le prestazioni di rete del client. I dati raccolti vengono visualizzati tramite un grafico interattivo nell’interfaccia client e inviati al backend per la memorizzazione e l’analisi storica.
Questa funzionalità è pensata per:
- Monitorare la qualità della comunicazione client–server
- Individuare anomalie di latenza e instabilità di rete
- Supportare attività di troubleshooting e analisi delle performance
Le metriche sono calcolate direttamente dal client e rappresentano le reali condizioni di rete percepite dall’utente.
Visualizzazione delle metriche
Nell’interfaccia client è disponibile un grafico temporale che si trova nel menu delle impostazioni sotto la voce Network Metrics.

Viene mostrata un’anteprima della qualità della connessione del client in tempo reale:
- buona
- mediocre
- scarsa
Cliccando sulla chip colorata si apre il grafico interattivo che mostra le metriche in tempo reale degli ultimi 5 minuti circa.

I dati mostrati nel grafico sono:
- TTR: misura la latenza di rete;
- Jitter: misura quanto stabile è questa latenza nel tempo (stabilità della connessione).
Cliccando sulla voce Show graph meaning si apre una sezione che descrive i dati con i relativi valori di riferimento.

Nell’interfaccia di amministrazione di Oplon Secure Access all’indirizzo: https://<your-ip>:4444
si possono trovare le metriche di tutti i client andando su: Running Status > Reports, selezionando il DB a cui sono stati inviati i dati e poi su User Network Metrics.