OK, le risposte sono in vendita, pagane una prendi tre gratuitamente oggi! :-) Prendiamoli in ordine ...
1.A. Il valore MCAUSER del canale è l'ID con cui vengono eseguiti i controlli di autorizzazione. Se lo DEFINE CHL() CHLTYPE(SVRCONN) lascia vuoto MCAUSER, i client che si connettono possono specificare l'ID a cui desiderano connettersi. Se non riescono a specificare, il client WMQ tenta di utilizzare l'ID dell'utente client visualizzato dalla workstation su cui è in esecuzione l'app client e presentarlo. L'impostazione di MCAUSER nella definizione del canale impedisce all'app client di specificare il valore.
1.B. Il MCAUSER in una regola ADDRESSMAP viene utilizzato per mappare MCAUSER in base ad alcuni criteri di identificazione. Si dice "IF una connessione arriva su questo canale con un indirizzo IP specifico | User Name | SSL Nome distinto POI uso questo ID come il MCAUSERE permettono il canale da eseguire se non altro blocco regole esso.
la raccomandazione, se una regola CHLAUTH mapping viene utilizzato di solito per impostare del MCAUSER ad un valore che non può essere un ID utente in modo che non verrà eseguito. in questo modo le impostazioni predefinite del canale ad uno stato sicuro a meno che un CHLAUTH canale regola sovrascrive il MCAUSER su un valore destinato a consentire l'accesso Il valore essenziale per MCAUSER era nobody fino a quando Mark Taylor, WMQ Strategist di Hursley Lab, suggeriva di utilizzare un valore che non può essere un ID utente effettivo, come ad esempio no#body. A partire da WMQ V7.1 il valore *NOACCESS è un lavoro riservato e ciò che sto utilizzando nelle presentazioni della conferenza in questi giorni.
2. Sì. WMQ autorizza in base ai gruppi. Il consiglio standard è di decostruire i requisiti di sicurezza in ruoli come "admin", "app1", "app2", "monitoring", "anonymous", ecc. Quindi, per ciascuno di questi ruoli che richiede l'accesso, creare un gruppo.
Ma le richieste di accesso provengono da entità identificate in modo univoco, non da gruppi. Il controllo dell'autorizzazione richiede che un account venga verificato, pertanto MCAUSER nel canale è un ID mentre i diritti di autorizzazione sono archiviati per gruppo. Per associare un utente ai diritti corretti, iscriverli al gruppo giusto.
Questo è il modello di autorizzazione UNIX standard che supporta la separazione dei compiti. Gli amministratori delle risorse (l'amministratore WMQ) autorizzano i gruppi. Gli amministratori degli account registrano gli ID utente in gruppi. Richiede l'accesso a entrambi i gruppi. Nel mondo reale, la maggior parte dei negozi non utilizza la funzione di separazione delle funzioni, ma in casi significativi è obbligatoria.
3. Tipo di. Un QMgr predefinito alla versione V7.1 o successiva non consente alcuna connessione remota. Questo perché quando viene creato non ha le regole AUTHREC in modo che ai non amministratori non venga concesso l'accesso. Gli amministratori sono bloccati dall'accesso remoto dalla regola predefinita CHLAUTH.
Con le regole specificate, chiunque può connettersi al canale $cname e verrà autorizzato come tcs-mq-user. Se si desidera che si colleghino come un altro ID utente con gli stessi privilegi, sarà quindi necessario aggiungere quell'ID al gruppo mq-user e quindi impostare il canale per mappare gli ID presentati. Se si desidera applicare l'ID a cui è stato collegato qualcuno, in quanto è necessario specificare la mappatura in base all'indirizzo IP o, meglio ancora, in base al nome distinto del certificato.
4. No. Come indicato in # 2 sopra, le richieste di accesso vengono sempre effettuate dai principal, non dai gruppi. L'intero punto delle regole CHLAUTH, MCAUSER e il mapping del nome distinto servono a risolvere l'ID utente utilizzato dal canale per i controlli di autorizzazione. La definizione del canale MCAUSER è un controllo di sicurezza in tale processo di risoluzione dell'ID e pertanto opera sull'ID e non sul gruppo.
Se non hai ancora trovato il sito, potresti trovare utile T-Rob.net. In particolare, nella pagina Link ho pubblicato tutte le presentazioni di WMQ Security dalle conferenze e link ai miei articoli e ad altri autori.
Come sempre molto grave risposta. Per quanto riguarda l'elemento 3 della tua risposta, dici * chiunque * può connettersi a $ cname ... Ora lo capisco da una modalità client. Che ne dici di modalità binding, è vero anche lì? – arrehman
nelle associazioni, o modalità di memoria condivisa, ho bisogno di passare a tcs-mq-utente giusto? Cosa succede se tcs-mq-user è un ID non di accesso? – arrehman
In modalità binding, non viene utilizzato alcun canale. È una connessione diretta da memoria a memoria. Le regole CHLAUTH e la definizione del canale si applicano solo quando la connessione viene effettuata tramite lo stack di rete. Se si desidera che tcs-mq-user si connetta in modalità binding, tale ID deve essere in grado di eseguire un processo. Quindi, a seconda di cosa "non-login" significa nel tuo negozio potrebbe essere necessario renderlo un account di accesso per eseguire processi localmente. (Alcuni negozi configurano "non-login" in modo tale che le shell interattive non sono consentite, ma root può ancora avviare un processo in esecuzione come tale ID. Il tuo chilometraggio può variare.) –