Abilitare un modulo di protocollo in WiKID

Introduzione

I moduli di protocollo consentono al server WiKID Strong Authentication di comunicare con diversi tipi di client di rete. L’edizione Community del server WiKID supporta, al momento, LDAP, TACACS+ e wAuth.

Definizione rapida: wAuth è il protocollo nativo di WiKID che usa SSL e autenticazione tramite certificati per trasmettere dati di autenticazione su una rete insicura.

Il sistema di dimostrazione per la registrazione (/opt/WiKID/tomcat/webapps/WiKIDAdmin/example.jsp o https://servername/WiKIDAdmin/exmample.jsp) usa un Java bean (wClient) per verificare le informazioni di autenticazione utente. Vedi la documentazione per modificare questo file.

Avviare l’inizializzazione dei moduli di protocollo

Seleziona l’intestazione [Protocol Modules] per iniziare l’inizializzazione. Vedrai un elenco dei moduli di protocollo disponibili sul server, come mostrato nella figura seguente.

Figura 16 – Elenco dei protocolli non inizializzati nell’interfaccia WiKID

Importante: il protocollo wAuth viene abilitato automaticamente, poiché gli altri protocolli non funzionano senza di esso.

Abilitare il protocollo LDAP

Per abilitare LDAP, clicca sul protocollo LDAP nella pagina Enable Protocols per aprire la pagina Enable LDAP. I parametri richiesti per il modulo LDAP sono:

LDAP_wauth_host: Indirizzo IP del server WiKID che convaliderà le richieste di bind LDAP (sempre 127.0.0.1)

LDAP_wauth_kfile: Percorso del certificato client di rete per l’accesso LDAP al server WiKID (di solito /opt/WiKID/private/localhost.p12)

LDAP_wauth_pass: Passphrase per il certificato client di rete sopra.

LDAP_wauth_port: Porta su cui il server WiKID è in ascolto (di solito 8388) NB: LDAP ascolterà effettivamente sulla porta 10389

LDAP_wauth_server: Codice a 12 cifre del dominio contro cui LDAP verificherà le richieste di bind

Dopo aver inserito i valori richiesti, clicca su Update per salvare la configurazione.

Creare client di rete

I client di rete sono sistemi che richiedono la validazione di one-time password (OTP) al server WiKID. Agiscono come proxy: raccolgono informazioni dagli utenti e le inoltrano al server WiKID per la convalida. Un client di rete utilizza uno dei moduli di protocollo installati. Prima di aggiungere un client, il relativo modulo deve essere installato, inizializzato e abilitato.

Ogni client di rete dev’essere configurato sul server WiKID prima di poter effettuare richieste di validazione. Per i client wAuth è necessario generare un certificato per il client di rete. L’eccezione è il client localhost preinstallato. È consigliabile rigenerare periodicamente questo certificato e quelli dei client remoti.

Figura 17 – Schermata iniziale dei client di rete

Seleziona Create new Network Client per iniziare l’aggiunta. Vedrai una schermata simile a quella sottostante.

Figura 18 – Proprietà del client di rete

Proprietà generali del client di rete

Questi valori sono obbligatori per ogni client, indipendentemente dal protocollo scelto.

• Name – Nome descrittivo del server. Usalo come etichetta principale nel pannello amministrativo e nei log. Consiglio: hostname + dominio WiKID per chiarezza.
• IP Address – Indirizzo IP del client di rete.
• Protocol – Protocollo di comunicazione del client. Sono disponibili solo i protocolli già abilitati. La scelta del protocollo definisce ulteriori proprietà richieste.
• Domain – Dominio di autenticazione WiKID in cui il client richiederà la convalida delle credenziali.

Se crei un client wAuth, dovrai generare un certificato per il client di rete e fornire le informazioni richieste.

Figura 19 – Creazione del certificato per un client di rete wAuth

Nota: il nome usato nel certificato non deve necessariamente essere un FQDN routabile. Puoi usare un nome host semplice o un nickname (ad esempio “www” o “extranet”) invece di “vpn.wikidsystems.com”.

Procedura passo-passo (mini-metodologia)

1. Accedi all’interfaccia amministrativa WiKID con un account admin.
2. Vai a [Protocol Modules] e verifica i moduli disponibili.
3. Assicurati che wAuth sia abilitato (dovrebbe esserlo automaticamente).
4. Per LDAP/TACACS+: apri la pagina Enable per il protocollo e inserisci i parametri richiesti. Salva con Update.
5. Crea il Network Client: Create new Network Client → compila Name, IP Address, Protocol, Domain.
6. Se usi wAuth: genera il certificato client e scarica il file .p12/.pem per l’installazione sul client.
7. Testa la convalida OTP da un client di prova prima di mettere il sistema in produzione.
8. Pianifica la rotazione periodica dei certificati (es. ogni 6–12 mesi).

Checklist ruolo-specifiche

Amministratore WiKID

• Verificare la presenza di backup recenti prima di modifiche.
• Abilitare solo i protocolli necessari.
• Monitorare i log di autenticazione dopo l’attivazione.

Ingegnere di rete

• Assicurarsi che i firewall permettano il traffico sulle porte configurate (8388, 10389 per LDAP, porte wAuth).
• Installare il certificato client su ogni sistema che funge da client wAuth.

Responsabile sicurezza

• Richiedere la rotazione dei certificati e la gestione sicura delle chiavi.
• Valutare l’uso di HSM o KMS per conservare le chiavi private.

Template di configurazione e verifica

Esempio di valori da compilare (modifica secondo l’ambiente):

• Name: vpn-gateway-1
• IP Address: 192.0.2.10
• Protocol: wAuth
• Domain: 123456789012
• LDAP_wauth_host: 127.0.0.1
• LDAP_wauth_kfile: /opt/WiKID/private/localhost.p12
• LDAP_wauth_pass:
• LDAP_wauth_port: 8388

Verifiche di accettazione (Test cases)

• Il client invia richieste di autenticazione e riceve risposta 200/OK dal server.
• Le richieste LDAP vengono accettate dal dominio specificato.
• Un client con certificato scaduto riceve un rifiuto.

Sicurezza: hardening e best practice

• Conserva i file .p12/.pem in storage cifrato. Limitane l’accesso ai soli amministratori necessari.
• Usa passphrase robuste per i certificati e cambia le passphrase se c’è sospetto di compromissione.
• Abilita logging dettagliato per wAuth e LDAP per poter eseguire audit e forensic.
• Applica patch regolari al server WiKID e al sistema operativo.
• Considera l’uso di canali management separati per le operazioni amministrative.

Procedure di incident response e rollback

Se un certificato client viene compromesso:

1. Revoca il certificato nel pannello amministrativo WiKID.
2. Rimuovi o disabilita il client di rete compromesso.
3. Genera un nuovo certificato e sostituisci il file sul client.
4. Aggiorna log e invia notifica agli stakeholder.
5. Se il compromesso include credenziali utente, esegui reset e notifica gli utenti interessati.

Rollback di una configurazione errata

• Ripristina i parametri dal backup o reimposta i valori precedenti manualmente.
• Se necessario, ripristina snapshot della VM o backup del file system.

Compatibilità e suggerimenti per migrazione

• Controlla le versioni di WiKID e dei moduli prima della migrazione. Alcune opzioni di configurazione possono cambiare tra le release.
• Testa ogni protocollo in un ambiente di staging prima della migrazione in produzione.
• Documenta i mapping degli IP e i domini per evitare conflitti.

Diagramma decisionale per scegliere il protocollo (Mermaid)

flowchart TD
  A[Serve autenticazione tramite directory aziendale?] -->|Sì| B[Usare LDAP]
  A -->|No| C[Serve integrazione via AAA?|]
  C -->|Sì| D[Considerare TACACS+]
  C -->|No| E[Client diretti o certificati?]
  E -->|Certificati| F[Usare wAuth]
  E -->|Altro| G[Valutare integrazione custom]

Glossario (1 riga per termine)

• wAuth: protocollo nativo WiKID basato su SSL e certificati per l’autenticazione.
• Network Client: sistema che richiede la validazione OTP al server WiKID.
• LDAP: protocollo di directory usato per autenticare bind e utenti.
• Certificate Authority (CA): autorità che firma certificati usati per autenticazione.

Fact box: numeri e raccomandazioni chiave

• Rotazione certificati: raccomandata ogni 6–12 mesi.
• Porte comuni: wAuth (configurata, tipicamente 8388), LDAP effettivo 10389.
• Dominio WiKID: codice a 12 cifre richiesto per LDAP_wauth_server.

Quando questa procedura potrebbe fallire (controesempi)

• Il firewall blocca le porte configurate: il traffico non arriva al server.
• Il file del certificato è corrotto o la passphrase è errata: autenticazione fallita.
• Il dominio WiKID non corrisponde: le richieste LDAP vengono rifiutate.

Note finali e riepilogo

Abilitare e configurare moduli di protocollo in WiKID richiede attenzione ai parametri e alla sicurezza dei certificati. wAuth è fondamentale e deve sempre essere operativo. Testare ogni client in ambiente controllato prima della messa in produzione riduce rischi operativi.

Importante: conserva copie di backup delle configurazioni e prevedi una procedura di rotazione dei certificati. Se si verifica un incidente, revoca immediatamente i certificati compromessi e rigenera nuove chiavi.

Riepilogo rapido:

• Verifica moduli in [Protocol Modules]
• Configura LDAP/TACACS+ con i parametri corretti
• Crea client di rete e genera certificati per wAuth
• Applica hardening e pianifica rotazione certificati