Abilitazione dell'autenticazione per le connessioni TCP/IP in entrata

È possibile impostare una comunicazione autenticata utilizzando una coppia di chiavi private e pubbliche quando si utilizza l'opzione TCPIP dalle opzioni di runtime TEST.

Nota: i passaggi relativi alla generazione del certificato e al suo caricamento sull'host sono gli stessi descritti in Abilitazione della comunicazione sicura tra z/OS Debugger e il debugger remoto per le sessioni di debug in entrata.

Eseguire le seguenti operazioni:

Aggiungere un certificato client esportando una copia del certificato client dal keystore utilizzato dal debugger remoto.
Questo certificato client viene utilizzato dal server TCP/IP z/OS Debugger (debugger remoto) durante l'autenticazione di Debug Daemon. Se il debugger remoto ha una connessione sicura, questo certificato può essere riutilizzato per l'autenticazione. Altrimenti, è possibile utilizzare l'utilità di runtime Java™ per creare un keystore, un certificato e l'esportazione di un certificato client.
- Creare un keystore e un certificato con il seguente comando:
```
keytool -genkey
```
- Esportare un certificato client utilizzando il seguente comando:
```
keytool -export
```
Nota: per l'insieme completo dei parametri richiesti per il comando keytool, consultare la documentazione Java appropriata.

Ogni utente di Eclipse IDE deve configurare il demone di debug per avviare una porta con la posizione e la password del keystore creato in precedenza. Per configurare il daemon di debug, vai alla pagina Esegui/Esegui debug > Preferenza Debug Daemon . Per ulteriori informazioni, consultare la sezione delle preferenze di Debug Daemon in Impostazione delle preferenze di debug.
Caricare il certificato su z/OS in modalità binaria e memorizzarlo come file z/OS Unix o come dataset sequenziale con HLQ come nome utente. Ad esempio, IBMUSER.DEBUG.CERT.
Passare il percorso del certificato come parametro alla sessione di debug, fornendo un EQACERT DD che punta al percorso del certificato.
Ad esempio:
```
//EQACERT DD *
IBMUSER.DEBUG.CERT
```
Per eseguire il debug dei programmi z/OS Unix, è possibile sostituire EQACERT DD con una variabile d'ambiente.
```
export EQACERT=/u/ibmuser/debug.cert
```
Ora è possibile specificare la posizione del certificato quando si crea un profilo di debug dalla schermata principale di DTCN o dalla vista Profili debugger di z/OS in Eclipse IDE.
- Per i profili CICS, vedere Creazione di un profilo di debug per un'applicazione CICS con una Eclipse IDE.
- Per i profili non CICS, vedere Creazione di un profilo di debug per un'applicazione non CICS con un Eclipse IDE.
- Per i profili di IMS Isolamento, vedere Creazione di un profilo di debug per un'applicazione IMS utilizzando IMS Isolamento con un Eclipse IDE.
Nota: il supporto dell'autenticazione TCP/IP per i profili di debug è disponibile solo nell'host z/OS Debugger versione 17.0.2 o successiva.

z/OS debugger v 17.0.x definisce una nuova sotto-opzione TEST TCPAUTH&ip_address%port simile alla sotto-opzione TCPIP&. Tuttavia, richiede una connessione remota per essere autenticata.

Dopo che l'autenticazione è riuscita, l'HLQ del set di dati del certificato o il proprietario del file Unix del certificato è considerato l'utente del debug e il nome utente viene verificato per l'accesso ai moduli di carico del debug durante i controlli di autorizzazione del debugger. Per forzare l'autenticazione su tutte le connessioni TCP, anche quando si utilizzano le sotto-opzioni TCPIP, è necessario definire un profilo SAF/ RACF EQAAUTH.TCP, con accesso NONE nella classe FACILITY. Se il profilo è indefinito o definito con accesso READ o superiore, l'opzione TCPIP non richiede autenticazione.

Nota : Alcuni prodotti di sicurezza potrebbero restituire l'accesso NESSUNO per profili non definiti, forzando così l'autenticazione TCPIP. Se si desidera continuare a utilizzare TCPIP senza autenticazione, definire EQAAUTH.TCP con accesso READ o superiore.