Servizi di autenticazione

I servizi di autenticazione sono supportati solo tra applicazioni client che utilizzano WebSphere MQ Real-time Transport e i nodi Real-timeInput e Real-timeOptimizedFlow WebSphere Message Broker.

I servizi di autenticazione WebSphere Message Broker verificano l'identità di un broker e di un'applicazione client in modo da poter quindi partecipare ad una sessione di pubblicazione/sottoscrizione.

Ciascun partecipante alla sessione utilizza un protocollo di autenticazione per dimostrare la propria identità, che non è quindi quella di un intruso che si impersona in un partecipante valido.

Il prodotto WebSphere Message Broker supporta i seguenti quattro protocolli:

I primi due protocolli ed i relativi requisiti di infrastruttura sono descritti rispettivamente in Autenticazione password telnet-like semplice e Autenticazione password challenge-response reciproca. I protocolli SSL asimmetrici e simmetrici sono descritti in Autenticazione SSL.

I protocolli variano a seconda del livello di protezione fornito nei confronti dei partecipanti non validi nella sessione; P è quello di livello inferiore mentre R è quello di livello superiore.

Configurazione dei protocolli di autenticazione

La serie di protocolli che può essere supportata da un determinato broker nel dominio broker può essere configurata utilizzando il workbench. Per ogni broker è possibile specificare uno o più protocolli. Utilizzare il workbench per abilitare o disabilitare l'autenticazione su ciascun nodo Real-timeInput definito per un determinato broker. Quando è abilitata l'autenticazione su un nodo Real-timeInput, questo supporta la serie completa di protocolli specificati per il relativo broker corrispondente. Le opzioni di configurazione sono illustrate nei seguenti diagrammi:

Panoramica della configurazione di autenticazione

Panoramica della configurazione di autenticazione
Processo di autenticazione runtime in due fasi

Questo diagramma mostra la fase 1 del processo di autenticazione runtime; il protocollo per la sessione è determinato.

Questo diagramma mostra la fase 2 del processo di autenticazione runtime; all'applicazione è sia consentito che negato l'accesso alla sessione.

Autenticazione password telnet-like semplice

Questo protocollo può essere anche descritto come password in chiaro poiché la password passa non crittografata in rete. L'applicazione client si collega al nodo Real-timeInput utilizzando TCP/IP. Il nodo di input richiede l'identificazione da parte del client. Il client invia "userid" e password relativa.

Questo semplice protocollo si basa sul fatto che entrambi il client e il broker conoscono la password associata ad un ID utente. In particolare, il broker deve accedere ad un archivio di informazioni relative all'utente e alla password. L'ID utente e la password vengono distribuiti dal Server nomi utente a tutti i broker in un dominio del prodotto WebSphere Message Broker. Il Server nomi utente estrae le informazioni relative all'utente e alla password da un file del sistema operativo.

L'approccio del Server nomi utente consente la gestione centralizzata dell'origine di utenti e password, con la distribuzione automatica delle informazioni ai broker e l'aggiornamento automatico delle informazioni, se richiesto. Fornisce inoltre vantaggi relativi alla disponibilità in quanto le informazioni relative a utente e password vengono conservate in modo persistente in ciascun broker.

Ogni applicazione client deve conoscere il relativo ID utente e tenere segreta la propria password. Quando si crea una connessione, un client specifica le relative credenziali come una combinazione di nome/password.

Questo protocollo fornisce una relativa sicurezza. Non calcola una chiave di sessione e deve essere utilizzato solo in ambienti in cui non sono presenti "intrusi".

Nel caso in cui le informazioni relative all'utente e alla password vengono memorizzate in un file di testo sul sistema del server nomi utente, le password vengono memorizzate e distribuite "in chiaro".

Il carico computazionale su client e server è molto leggero.

Autenticazione password challenge-response reciproca

Questo protocollo è più sofisticato e sicuro e implica la creazione di una chiave di sessione segreta. Sia il client che il server calcolano questa chiave utilizzando la password del client. Questi dimostrano reciprocamente di conoscere tale informazione mediante un protocollo challenge-response.

Il client deve rispondere alla domanda del server prima che il server risponda a quella del client. Ciò significa che un intruso che impersona un client non può ottenere alcuna informazione per tentare di indovinare una password "offline". Sia il client che il server dimostrano la conoscenza reciproca della password, cosicché questo protocollo non è vulnerabile ad attacchi di "personificazione".

Come nel caso del protocollo di password telnet-like semplice, il broker deve avere accesso alle informazioni relative all'utente e alla password. L'ID utente e la password vengono distribuiti dal server nomi utente a tutti i broker nel dominio. Il server nomi utente estrae le informazioni relative all'utente e alla password da un file del sistema operativo.

Ogni applicazione client deve conoscere il relativo ID utente e tenere segreta la propria password. Quando si crea una connessione, un client specifica le relative credenziali come una combinazione di nome/password.

Le domande computazionali su entrambi client e server sono alquanto modeste.

Informazioni particolari | Marchi | Download | Libreria | Supporto | Commenti
Copyright IBM Corporation 1999, 2006 Ultimo aggiornamento: ago 17, 2006
aq01206_