Domini di sicurezza multipli

Perché i domini di sicurezza sono utili

WebSphere I domini di sicurezza offrono due vantaggi principali:

Nelle versioni precedenti di WebSphere Application Server, tutte le applicazioni amministrative e utente condividono la maggior parte degli attributi di sicurezza. Tutte le applicazioni amministrative e utente in WebSphere Application Server utilizza gli attributi di sicurezza globali per impostazione predefinita. Ad esempio, un registro utenti definito nella sicurezza globale viene utilizzato per autenticare un utente per ogni applicazione nella cella.

In questa versione di WebSphere Application Server, tuttavia, puoi utilizzare più attributi di sicurezza per le applicazioni utente diversi dagli attributi di sicurezza globali, creare un dominio di sicurezza per quegli attributi di sicurezza che devono differire e associarli ai server e ai cluster che ospitano tali applicazioni utente. Puoi anche associare un dominio di sicurezza alla cella. Tutte le applicazioni utente nella cella utilizzano questo dominio di sicurezza se non hanno un dominio precedentemente associato ad esse. Tuttavia, gli attributi di sicurezza globali sono ancora necessari per le applicazioni amministrative come la console amministrativa, le risorse di denominazione e gli MBean.

Se hai utilizzato la sicurezza a livello di server nelle versioni precedenti di WebSphere Application Server, ora dovresti utilizzare più domini di sicurezza poiché sono più flessibili e più facili da configurare.

La sicurezza a livello di server è deprecata in questa versione. Leggere Relazione tra sicurezza globale e domini di sicurezza per maggiori informazioni.

Relazione tra sicurezza globale e domini di sicurezza

La sicurezza globale si applica a tutte le funzioni amministrative e alla configurazione di sicurezza predefinita per le applicazioni utente. I domini di sicurezza possono essere utilizzati per definire una configurazione personalizzata per le applicazioni utente.

È necessario definire una configurazione di sicurezza globale prima di poter creare domini di sicurezza. La configurazione di sicurezza globale viene utilizzata da tutte le applicazioni amministrative come la console amministrativa, le risorse di denominazione e gli Mbean. Se non è configurato alcun dominio di sicurezza, tutte le applicazioni utilizzano le informazioni della configurazione di sicurezza globale. Applicazioni utente come Enterprise JavaBeans (EJB), servlet e applicazioni amministrative utilizzano la stessa configurazione di sicurezza.

Quando si crea un dominio di sicurezza e lo si associa a un ambito, solo le applicazioni utente in quell'ambito utilizzano gli attributi di sicurezza definiti nel dominio di sicurezza. Le applicazioni amministrative e le operazioni di denominazione in tale ambito utilizzano la configurazione di sicurezza globale. Definire gli attributi di sicurezza a livello di dominio che devono essere diversi da quelli a livello globale. Se l'informazione è comune, non è necessario che il dominio di sicurezza contenga informazioni duplicate. Tutti gli attributi mancanti nel dominio vengono ottenuti dalla configurazione globale. I dati di configurazione della sicurezza globale sono archiviati nel filesecurity.xml file, che si trova nel file$WAS_HOME/profiles/$ProfileName/cells/$CellName directory.

La figura seguente fornisce un esempio di dominio multiplo di sicurezza in cui la cella, un server e un cluster sono associati a domini di sicurezza diversi. Come mostrato nella figura, le applicazioni utente nel serverS1.1 così come il cluster utilizzano gli attributi di sicurezza definiti inDomain2 EDomain3 rispettivamente (poiché questi ambiti sono associati a questi domini). serverS2.2 non è associato a un dominio. Di conseguenza, l'applicazione utente inS2.2 utilizza il dominio associato alla cella (Domain1 ) per impostazione predefinita. Gli attributi di sicurezza mancanti a livello di dominio vengono ottenuti dalla configurazione globale.

La figura seguente mostra i vari attributi di sicurezza di alto livello che possono essere definiti nella configurazione di sicurezza globale e quelli che possono essere sovrascritti a livello di dominio.

Contenuto di un dominio di sicurezza

Un dominio di sicurezza è rappresentato da due file di configurazione. Un file di configurazione contiene l'elenco degli attributi configurati nel dominio di sicurezza. L'altro file di configurazione contiene gli ambiti che utilizzano il dominio di sicurezza. Le informazioni sul dominio di sicurezza sono archiviate nel file$WAS_HOME/profiles/$ProfileName/config/waspolicies/default/securitydomains/$SecurityDomainName directory. Per ogni dominio di sicurezza configurato, a$SecurityDomainName viene creata una directory con due file al suo interno: thesecurity-domain.xml il file contiene l'elenco degli attributi di sicurezza configurati per il dominio di sicurezza e il filesecurity-domain-map.xml il file contiene gli ambiti che utilizzano il dominio di sicurezza.

La figura seguente indica la posizione dei principali file relativi al dominio di sicurezza e il contenuto di tali file.

Creazione di domini di sicurezza

Utilizzare le attività della console di gestione o i comandi di script per creare domini di sicurezza. Nella console di amministrazione, accedi ai domini di sicurezza facendo clic su Sicurezza > Domini di sicurezza . La guida è disponibile per ciascun pannello della console di amministrazione.

Per un elenco completo delle attività della console di gestione e dei comandi di scripting, vedere i collegamenti in "Attività correlate" alla fine di questo documento.

Quando crei un dominio di sicurezza devi fornire un nome univoco per il dominio, gli attributi di sicurezza che desideri configurare per il dominio di sicurezza e gli ambiti che devono utilizzare il dominio di sicurezza. Una volta configurati, i server che utilizzano il dominio di sicurezza devono essere riavviati. Le applicazioni utente in tali ambiti utilizzano quindi gli attributi definiti nel dominio di sicurezza. Tutti gli attributi non configurati a livello di dominio vengono ottenuti dalla configurazione della sicurezza globale. Le applicazioni amministrative e le operazioni di denominazione negli ambiti utilizzano sempre gli attributi di sicurezza della configurazione di sicurezza globale. È necessario gestire attivamente questi attributi.

Eventuali nuovi attributi del dominio di sicurezza devono essere compatibili con gli attributi di sicurezza globali ereditati dalle applicazioni utente assegnate al dominio.

Altro che per JAAS e proprietà personalizzate, una volta personalizzati gli attributi globali per un dominio non vengono più utilizzati dalle applicazioni utente.

Il pannello dei domini di sicurezza nella console di amministrazione ti consente di assegnare risorse e selezionare gli attributi di sicurezza appropriati per il tuo dominio. Il pannello visualizza gli attributi chiave di sicurezza nella configurazione globale; puoi decidere di sovrascriverli a livello di dominio, se necessario. Una volta configurati e salvati gli attributi a livello di dominio, il valore di riepilogo nel pannello visualizza il valore personalizzato per il dominio (contrassegnato con la parola "personalizzato" in testo nero).

Un ambito (un server, un cluster, un bus di integrazione dei servizi o una cella) può essere associato a un solo dominio. Ad esempio, non è possibile definire due domini che abbiano entrambi l'ambito a livello di cella. È tuttavia possibile definire più ambiti nello stesso dominio di sicurezza. Ad esempio, è possibile definire l'ambito di un dominioServer1 e aServer2 solo all'interno della cellula.

La sezione degli ambiti assegnati nel pannello del dominio di sicurezza presenta due visualizzazioni: una visualizzazione che consente di selezionare e assegnare ambiti al dominio e un'altra visualizzazione che consente di visualizzare un elenco degli ambiti attualmente assegnati. Per comodità, hai anche la flessibilità di copiare tutti gli attributi di sicurezza da un dominio di sicurezza esistente o dalla configurazione globale in un nuovo dominio di sicurezza e quindi modificare solo gli attributi che devono essere diversi. È comunque necessario associare gli ambiti a questi domini copiati.

I comandi di scripting forniscono inoltre la possibilità di creare, copiare e modificare domini di sicurezza. Una volta creato un dominio, è necessario eseguire i comandi appropriati per associarvi attributi e ambiti di sicurezza.

Configurazione degli attributi per i domini di sicurezza

Attributi di sicurezza che possono essere configurati a livello di dominio in WebSphere Application Server Versione 8.5 Sono:

I pannelli dei domini di sicurezza nella console di amministrazione visualizzano tutti questi attributi di sicurezza.

Alcuni degli altri attributi noti che non è possibile sovrascrivere a livello di dominio lo sono Kerberos, Audit, Web Single Sign-on (SSO) e Tivoli® Access Manager (TAM). L'attributo Secure Socket Layer (SSL) supporta già diversi ambiti, ma non fa parte della configurazione del dominio. Per tutti gli attributi che non sono supportati a livello di dominio, le applicazioni utente in un dominio condividono la propria configurazione a livello globale.

Eventuali nuovi attributi del dominio di sicurezza devono essere compatibili con gli attributi di sicurezza globali ereditati dalle applicazioni utente assegnate al dominio. È necessario gestire attivamente questi attributi. Ad esempio, se personalizzi solo a JAAS configurazione a livello di dominio è necessario assicurarsi che funzioni con il registro utenti configurato a livello globale (se il registro utenti non è personalizzato a livello di dominio).

Altro che per JAAS e proprietà personalizzate, una volta personalizzati gli attributi globali per un dominio non vengono più utilizzati dalle applicazioni utente.

Il runtime del client Tivoli Access Manager viene utilizzato per fornire l'autenticazione (utilizzato da TrustAssociationInterceptor E PDLoginModule) e autorizzazione (utilizzata per JACC) contattando i server TAM. Esiste un solo runtime di Tivoli Access Manager condiviso da tutti i server in una cella. Per ulteriori informazioni, leggere l'argomento relativo alla configurazione del provider JACC di Tivoli Access Manager.

Non è possibile avere una configurazione diversa di Tivoli Access Manager a livello di dominio di sicurezza per sovrascrivere la configurazione a livello di cella. Tuttavia, è possibile specificare in una certa misura la configurazione Trust Association Interceptor (TAI) e JACC a livello di dominio di sicurezza. Ad esempio, puoi utilizzare un TAI diverso o un fornitore di autorizzazioni diverso. Poiché la connettività del server TAM può essere definita solo a livello globale, è possibile avere una varietà di TAI definiti e configurati a livello di dominio di sicurezza. Alcuni di questi TAI potrebbero non utilizzare il repository utente TAM, mentre altri lo fanno. I TAI che devono connettersi al TAM si connetteranno anche al server TAM definito a livello globale. Allo stesso modo, per l'autorizzazione, è possibile avere una varietà di provider di autorizzazione esterni configurati a livello di dominio. Tuttavia, se uno qualsiasi di questi fornitori di autorizzazioni esterni richiede la connessione al TAM, finisce per comunicare con il singolo server TAM configurato a livello globale.

Associazione degli ambiti ai domini di sicurezza

Quando un dominio di sicurezza è associato a un server che non fa parte di un cluster, tutte le applicazioni utente in quel server utilizzano gli attributi del dominio di sicurezza. Eventuali attributi di sicurezza mancanti vengono ottenuti dalla configurazione di sicurezza globale. Se il server fa parte di un cluster, è possibile associare il dominio di sicurezza al cluster ma non ai singoli membri di quel cluster. Il comportamento di sicurezza rimane quindi coerente in tutti i membri del cluster.

Se un server deve far parte di un cluster, creare prima un cluster e associarvi il dominio di sicurezza. Potresti aver associato un dominio a un server prima che diventasse membro di un cluster. In tal caso, anche se il dominio è associato direttamente al server, il codice runtime di sicurezza non esamina il dominio. Quando un server è un membro del cluster, il runtime di sicurezza ignora qualsiasi dominio di sicurezza associato direttamente al server. Rimuovere l'ambito del server dal dominio di sicurezza e associarvi invece l'ambito del cluster.

Alla cella è possibile associare anche un dominio di sicurezza. Questo di solito viene fatto quando vuoi associare tutte le applicazioni utente in WebSphere Application Server ad un dominio di sicurezza. In questo scenario, tutte le applicazioni amministrative e le operazioni di denominazione utilizzano la configurazione di sicurezza globale mentre tutte le applicazioni utente utilizzano la configurazione a livello di dominio. Se desideri dividere le informazioni sulla configurazione della sicurezza per le applicazioni amministrative e quelle utente, questo è tutto ciò che serve.

Se disponi di un ambiente con versioni miste o prevedi di averne uno in futuro e desideri associare domini di sicurezza a livello di cella, leggi Domini di sicurezza in un ambiente a versione mista per maggiori informazioni.

Se ci si trova su un server del profilo di base in cui è definito il proprio dominio di sicurezza, che viene quindi federato a un gestore distribuzione, associare l'ambito del server al dominio di sicurezza e non all'ambito della cella. Quando si federa quel nodo, le informazioni sul dominio di sicurezza vengono propagate al gestore distribuzione. Se l'ambito della cella è associato ad esso, la configurazione di distribuzione della rete utilizza questa configurazione di sicurezza, che potrebbe influire sulle applicazioni esistenti. Durante la federazione, l'ambito della cella viene modificato nell'ambito del server federato. Se l'ambito del server è associato al dominio di sicurezza, solo quel server utilizza il dominio di sicurezza dopo la federazione. Le altre applicazioni in altri server e cluster non sono interessate. Tuttavia, se questo server del profilo di base è registrato nel processo dell'agente amministrativo, è possibile associare l'ambito della cella al dominio di sicurezza se si desidera che tutti i server del profilo di base utilizzino lo stesso dominio di sicurezza per tutte le relative applicazioni utente. Leggi di più Federazione di un nodo con domini di sicurezza per maggiori informazioni.

È possibile avere un dominio di sicurezza associato a livello di cella e anche altri domini di sicurezza associati a vari cluster o singoli server (quelli che non fanno parte di alcun cluster). In questo caso, il runtime di sicurezza controlla innanzitutto se qualche dominio di sicurezza è associato al server o a un cluster. Se esiste un dominio di sicurezza associato al server o al cluster, gli attributi di sicurezza definiti in esso vengono utilizzati per tutte le applicazioni in quel server o cluster. Eventuali attributi di sicurezza mancanti da questo server o dominio cluster vengono ottenuti dalla configurazione di sicurezza globale e non dalla configurazione del dominio associata alla cella.

Se per il server o il cluster non è definito un proprio dominio, il codice runtime di sicurezza utilizza gli attributi di sicurezza del dominio associato alla cella (se ne è definito uno). Eventuali attributi di sicurezza mancanti dal dominio della cella vengono ereditati dalla configurazione di sicurezza globale.

Relazione tra la vecchia sicurezza a livello di server e i nuovi domini di sicurezza

Nelle versioni precedenti di WebSphere Application Server, potresti associare un piccolo insieme di attributi di sicurezza a livello di server. Questi attributi venivano utilizzati da tutte le applicazioni a livello di server. Il modo precedente di configurare gli attributi di sicurezza era deprecato in WebSphere Application Server 7.0 e verrà rimosso in una versione futura.

Ora dovresti utilizzare il nuovo supporto per i domini di sicurezza a partire da WebSphere Application Server 7.0, poiché questi domini di sicurezza sono gestiti più facilmente e sono molto più flessibili. Ad esempio, nelle versioni precedenti di WebSphere Application Server, è necessario associare manualmente la stessa configurazione di sicurezza a tutti i membri del cluster configurando gli stessi attributi di sicurezza per ogni server in un cluster.

Lo strumento di migrazione migra le informazioni sulla configurazione di sicurezza a livello di server esistente nella nuova configurazione del dominio di sicurezza quando è attiva la modalità di compatibilità degli script falso ( -scriptCompatibility="false" ). Viene creato un nuovo dominio di sicurezza per ogni configurazione di sicurezza del server se non fa parte di un cluster. Se fa parte di un cluster, un dominio di sicurezza viene associato al cluster anziché a tutti i server in quel cluster. In entrambi i casi, tutti gli attributi di sicurezza configurati a livello di server nei rilasci precedenti vengono migrati nella nuova configurazione del dominio di sicurezza e l'ambito appropriato viene assegnato ai domini di sicurezza.

Se la modalità di compatibilità dello script è impostata su VERO, la configurazione di sicurezza a livello di server non viene migrata alla nuova configurazione dei domini di sicurezza. La vecchia configurazione di sicurezza del server viene migrata senza alcuna modifica. Il runtime di sicurezza rileva l'esistenza della vecchia configurazione di sicurezza e utilizza tali informazioni, anche se un dominio di sicurezza è associato direttamente o indirettamente al server. Se la modalità di compatibilità dello script è impostata su VERO, rimuovere la configurazione di sicurezza dal livello del server e quindi creare un dominio di sicurezza con lo stesso insieme di attributi di sicurezza.

Come gli attributi di sicurezza a livello di dominio vengono utilizzati dal runtime di sicurezza e dalle applicazioni

Questa sezione descrive come i singoli attributi a livello di dominio vengono utilizzati dal runtime di sicurezza e come ciò influisce sulla sicurezza dell'applicazione utente. Poiché tutti questi attributi di sicurezza sono definiti anche a livello globale, maggiori informazioni su questi attributi possono essere ottenute altrove. Ai fini di questa sezione, l'enfasi è posta sul comportamento a livello di dominio.

Modello di programmazione della sicurezza del client e dell'applicazione quando si utilizzano domini di sicurezza

Un client Java o un'applicazione che funge da client che accede a un EJB in genere esegue prima una ricerca dei nomi. La risorsa di denominazione, utilizzata sia dalle applicazioni amministrative che da quelle utente, è considerata una risorsa amministrativa. È protetto dalle informazioni di configurazione della sicurezza globale. In una configurazione con più domini in cui la sicurezza globale utilizza un ambito (il registro utente) e un dominio utilizza un ambito diverso, il client Java deve autenticarsi su due ambiti diversi. La prima autenticazione è richiesta per l'ambito nella configurazione di sicurezza globale affinché l'operazione di denominazione abbia esito positivo, mentre la seconda autenticazione è richiesta per accedere all'EJB, che utilizza un ambito diverso.

ILCosNamingRead Il ruolo protegge tutte le operazioni di lettura del nome. A questo ruolo viene solitamente assegnato ilEveryone argomento speciale. Ciò implica che qualsiasi utente, valido o meno, può cercare lo spazio dei nomi. Quando viene definito un dominio multiplo, se ilCosNamingRead il ruolo ha ilEveryone argomento speciale, il codice runtime di sicurezza sul lato client non richiede di accedere. Utilizza invece l'oggetto UNAUTHENTICATED per accedere all'operazione di denominazione. Una volta completata l'operazione di ricerca del nome, quando il client tenta di accedere all'EJB viene visualizzato un pannello di accesso che indica l'area attualmente utilizzata dall'applicazione EJB (ovvero l'area utilizzata nel dominio). Il client presenta quindi le credenziali utente appropriate per quel realm, che può quindi accedere all'EJB. Questa logica si applica a tutte le varianti dell'origine di accesso, inclusoproperties Estdin , non solo quando l'origine di accesso è impostata suprompt .

Se laEveryone l'argomento speciale viene rimosso dal fileCosNamingRead ruolo, ti verrà richiesto due volte. Se l'origine dell'accesso èproperties , puoi rimuovere il commento dal filecom.ibm.CORBA.loginRealm proprietà nel$WAS_HOME/profiles/$ProfileName/properties/sas.client.props file e aggiungi i reami appropriati utilizzando "|" come separatore. È inoltre necessario inserire gli utenti e le password corrispondenti nel filecom.ibm.CORBA.loginUserid Ecom.ibm.CORBA.loginPassword proprietà rispettivamente. Quando si utilizza l'accesso programmatico nel codice client Java è necessario autenticarsi due volte con credenziali utente diverse; una volta prima di eseguire una ricerca dei nomi per l'EJB (l'utente dovrebbe trovarsi nell'ambito globale) e successivamente prima di chiamare qualsiasi metodo nell'EJB (l'utente dovrebbe trovarsi nell'ambito del dominio EJB).

IL CosNamingRead ruolo definito nel z/OS il server di sicurezza non viene fatto riferimento per determinare se le operazioni di lettura della denominazione sono protette in un ambiente di dominio a sicurezza multipla, anche quando l'autorizzazione SAF è abilitata. Invece, le impostazioni nel fileadmin-authz.xml vengono utilizzati i file. In alternativa, puoi utilizzare la proprietà personalizzatacom.ibm.security.multiDomain.setNamingReadUnprotected per controllare se le operazioni di lettura del nome sono protette. Questa proprietà sovrascriverà qualsiasi assegnazione effettuata a CosNamingRead ruolo, indipendentemente dal provider di autorizzazione utilizzato.

In generale, quando un client Java deve autenticarsi su regni multipli e diversi, deve fornire le informazioni sulle credenziali per tutti questi regni. Se l'origine dell'accesso èprompt Ostdin viene richiesto di accedere più volte, una per ciascun reame. Se l'origine di accesso è impostata suproperties , le proprietà appropriate insas.client.props (o qualsiasi file correlato) vengono utilizzati per l'autenticazione in ambiti diversi.

In alcuni scenari, un client potrebbe effettuare più chiamate allo stesso realm. Ad esempio, il client Java può accedere a una risorsa utilizzandorealm1 seguito dall'accesso a una risorsa utilizzandorealm2 , quindi torna per accedere a una risorsa inrealm1 Ancora. In questo caso, al client viene richiesto tre volte; prima perrealm1 , in secondo luogo perrealm2 e infine perrealm1 Ancora.

Per impostazione predefinita, l'oggetto utilizzato per accedere a un realm non viene memorizzato nella cache dal codice lato client. Se si dispone di questo scenario e si desidera che il client memorizzi nella cache l'oggetto in base al dominio, impostare il filecom.ibm.CSI.isRealmSubjectLookupEnabled proprietà a VERO nelsas.client.props file. Se lacom.ibm.CSI.isRealmSubjectLookupEnabled è impostata, il codice client memorizza nella cache l'oggetto in base al nome dell'area di autenticazione. La prossima volta che il client Java dovrà autenticarsi in questo dominio, verrà individuata la cache per ottenere l'oggetto e al client non verrà richiesta l'autenticazione. Inoltre, quando ilcom.ibm.CSI.isRealmSubjectLookupEnabled è impostata, lo stesso oggetto che è stato effettuato l'accesso la prima volta viene utilizzato per gli accessi successivi. Se è necessario modificare le informazioni sull'oggetto, questa proprietà non deve essere impostata.

Se il client sta eseguendo un accesso programmatico, può passare il realm insieme all'utente e alla password necessari per l'autenticazione. In questo caso, quando ilcom.ibm.CORBA.validateBasicAuth la proprietà è impostata su VERO (il valore predefinito) nel filesas.client.props file, per l'accesso viene utilizzato il registro che corrisponde al nome dell'area di autenticazione. Quel regno deve essere supportato nel processo in cui avviene l'autenticazione.

Quando si utilizza WSLogin JAAS configurazioni, è inoltre necessario impostare il file use_realm_callback opzione nelwsjaas_client.config archiviare$WAS_HOME/profiles/$ProfileName/properties affinché il nome dell'area venga passato al gestore della richiamata. Se desideri specificare un URL del provider diverso per il server dei nomi, imposta il file use_appcontext_callback opzione e passare le proprietà dell'URL del provider in una mappa hash a WSLogin.

Se non conosci il nome del regno, usa <default > come nome del regno. L'autenticazione viene eseguita rispetto all'ambito dell'applicazione. Se l'operazione di lettura della denominazione non ha il fileEveryone oggetto speciale assegnato, è necessario fornire l'ambito utilizzato dalle applicazioni amministrative (il registro utilizzato nella configurazione di sicurezza globale), nonché le informazioni appropriate su utente e password in tale registro affinché l'operazione di ricerca abbia esito positivo.

Una volta completata l'operazione di ricerca, eseguire un altro accesso programmatico fornendo l'ambito dell'applicazione (o <default >) e le informazioni su utente e password per l'utente appropriato nel registro utilizzato dall'applicazione. Questo è simile al caso in cui si trova l'origine di accesso richiesta. È necessario autenticarsi due volte, una volta per il registro utilizzato dalla configurazione di sicurezza globale (per l'operazione di ricerca dei nomi) e un'altra volta per il registro utilizzato dall'applicazione per accedere all'EJB.

Secom.ibm.CORBA.validateBasicAuth è impostato per falso nel$WAS_HOME/profiles/$ProfileName/properties/sas.client.props file, l'accesso programmatico può utilizzare <default > come nome del realm sia per la ricerca che per le operazioni EJB. L'autenticazione vera e propria avviene solo quando si accede alla risorsa dal lato server, nel qual caso l'ambito viene calcolato in base alla risorsa a cui si accede.

Il nuovo supporto per il dominio di sicurezza inizierà a WebSphere Versione dell'applicazione 7.0 non modifica l'attuale modello di programmazione della sicurezza delle applicazioni. Tuttavia, offre maggiore flessibilità e funzionalità come le seguenti:

Distribuzione dell'applicazione in configurazioni con più domini

Quando si distribuisce un'applicazione in una configurazione con più domini, tutti i moduli dell'applicazione devono essere installati nei server o nei cluster che appartengono allo stesso dominio di sicurezza. In caso contrario, a seconda degli attributi di sicurezza configurati in questi domini di sicurezza, potrebbe verificarsi un comportamento incoerente. Ad esempio, se i domini contengono registri utenti diversi, le informazioni sugli utenti e sui gruppi possono essere diverse, il che può causare comportamenti incoerenti durante l'accesso ai moduli. Un altro esempio è quando il JAAS i dati sono diversi tra i domini di sicurezza. IL JAAS le configurazioni non sono accessibili da tutti i moduli dell'applicazione. Il codice runtime di sicurezza e le attività di comando si basano su un dominio associato a un'applicazione quando si gestiscono attributi quali registro utente, JAAS configurazioni di accesso, J2C dati di autenticazione e autorizzazione.

Nella maggior parte dei casi, la distribuzione dell'applicazione non riesce quando un'applicazione viene distribuita su domini diversi. Tuttavia, poiché ciò era possibile nelle versioni precedenti di WebSphere Application Server quando solo pochi attributi erano supportati a livello di server, lo strumento di distribuzione controlla innanzitutto gli attributi configurati nei domini. Se gli attributi nel dominio sono gli stessi supportati nelle versioni precedenti, la console di gestione richiede conferma per garantire che si desideri distribuire i moduli dell'applicazione su più domini di sicurezza. A meno che non vi sia un requisito assoluto di distribuire le applicazioni su domini diversi, interrompere la distribuzione e selezionare i server e i cluster nello stesso dominio di sicurezza.

Comunicazione tra regni

Quando le applicazioni comunicano utilizzando il protocollo RMI/IIOP e LTPA è il meccanismo di autenticazione, il token LTPA viene passato tra i server coinvolti. Il token LTPA contiene il dominio qualificato per l'ambito uniqueId, (chiamato anche ilaccessId ), dell'utente che accede all'applicazione front-end. Quando questo token viene ricevuto dal server downstream, tenta di decrittografarlo. Se le chiavi LTPA sono condivise tra i due server, la decrittografia ha esito positivo e il file accessId dell'utente è ottenuto dal token. Il regno nel accessId viene controllato con l'ambito corrente utilizzato dall'applicazione. Se i realm corrispondono, la validazione del token LTPA ha esito positivo e si procede con l'autorizzazione. Se gli ambiti non corrispondono, la convalida del token fallisce poiché l'utente dell'ambito esterno non può essere convalidato nell'ambito corrente dell'applicazione. Se non è previsto che le applicazioni comunichino tra loro quando si utilizza RMI/IIOP e il meccanismo di autenticazione LTPA, non è necessario fare altro.

Se vuoi che la comunicazione tra regni abbia successo quando usi i token RMI/IIOP e LTPA, devi prima stabilire la fiducia tra i reami coinvolti, sia per le comunicazioni in entrata che in uscita.

Per il server che origina la richiesta, il suo reame deve avere i regni di cui può fidarsi per inviare il token. Questo è indicato come outboundTrustedRealms. Per il server che riceve la richiesta, il suo reame deve fidarsi dei reami da cui può ricevere token LTPA. Questo è indicato come inboundTrustedRealms.

Gli ambiti attendibili in uscita possono essere stabiliti utilizzando il file addTrustedRealms comandare con il -communicationType opzione impostata su in uscita. Può anche essere stabilito nella console di amministrazione facendo clic suTrusted authentication realms - outbound sulCSIv2 outbound communications pannello.

Gli ambiti attendibili in entrata possono essere stabiliti utilizzando lo stesso addTrustedRealms compito di comando con il -communicationType opzione impostata su in entrata. Può anche essere stabilito utilizzando la console di amministrazione.

La figura più avanti in questa sezione mostra la comunicazione tra applicazioni che utilizzano diversi ambiti utente (registri) utilizzando RMI/IIOP. In questo esempio, applicationapp1 (ad esempio, aservlet ) è configurato per utilizzare il filerealm1 registro utenti. ILapp2 l'applicazione (ad esempio, un EJB) è configurata per utilizzare il filerealm2 registro utenti. L'utente (user1 ) inizialmente accede al servlet inapp1 , che tenta quindi di accedere a un EJB inapp2 . È necessario impostare quanto segue:

Quando il token LTPA che contiene il file accessId Diuser1 viene ricevuto daapp2 , decrittografa il token. Entrambi i server condividono le stesse chiavi LTPA. Il token LTPA garantisce quindi che il regno straniero sia un regno affidabile ed esegue l'autorizzazione in base al file accessId Diuser1 . Se la propagazione degli attributi di sicurezza non è disabilitata, le informazioni sul gruppo diuser1 viene anche propagato aapp2 . I gruppi possono essere utilizzati per il controllo dell'autorizzazione, a condizione che la tabella delle autorizzazioni contenga le informazioni sul gruppo. Puoi associare un argomento speciale,AllAuthenticatedInTrustedRealms , ai ruoli invece di aggiungere singoli utenti e gruppi alla tabella delle autorizzazioni.

Se le applicazioni dell'esempio precedente vengono distribuite in celle diverse, è necessario effettuare le seguenti operazioni:

Una volta stabilita la fiducia tra i regni, quando il server riceve il token LTPA e il token viene decrittografato, controlla se il reame straniero è nell'elenco dei reami attendibili in entrata. Se è attendibile, l'autenticazione ha esito positivo. Tuttavia, poiché si tratta di un regno straniero, non effettua ricerche nel registro utenti per raccogliere informazioni sull'utente. Qualunque informazione contenuta nel token LTPA viene utilizzata per autorizzare l'utente.

L'unica informazione nel token LTPA è l'ID univoco dell'utente. Questo ID univoco dell'utente dovrebbe esistere nella tabella delle autorizzazioni per questa applicazione. In tal caso, l'autorizzazione ha esito positivo. Tuttavia, se la propagazione degli attributi è abilitata, ulteriori attributi di autorizzazione (gruppi a cui appartiene l'utente) per l'utente vengono inviati dal server di origine al server ricevente. Questi attributi aggiuntivi vengono utilizzati per prendere le decisioni di accesso. Se le informazioni sui gruppi esistono nei token di propagazione, vengono utilizzate quando si prende la decisione sull'autorizzazione.

Come accennato in precedenza, le informazioni sugli utenti e/o sui gruppi degli ambiti attendibili dovrebbero essere presenti nella tabella di autorizzazione dell'applicazione ricevente. Nello specifico, il accessId degli utenti e/o dei gruppi dovrebbero esistere nel file vincolante dell'applicazione. Questo deve essere il caso quando l'applicazione viene distribuita. Nella console di amministrazione, quando un'applicazione viene distribuita in un dominio, è possibile aggiungere il file accessIds degli utenti e dei gruppi da qualsiasi dei suoi ambiti attendibili alla tabella delle autorizzazioni.

Hai anche la possibilità di associare un argomento speciale,AllAuthenticatedInTrustedRealms , ai ruoli invece di aggiungere singoli utenti e gruppi. Questo è simile alAllAuthenticated argomento speciale attualmente supportato. La differenza è che ilAllAuthenticated l'oggetto speciale si riferisce agli utenti nello stesso ambito dell'applicazione mentre il fileAllAuthenticatedInTrustedRealms un argomento speciale si applica a tutti gli utenti negli ambiti attendibili e nell'ambito dell'applicazione.

Puoi associare il accessId utilizzando il $AdminApp installa lo script. Perché il accessId accetta un formato univoco, utilizzare l'attività comandolistRegistryUsers condisplayAccessIds impostato VERO. Se in questo campo viene immesso un nome o un formato non valido, l'autorizzazione fallisce.

Le informazioni su utenti e gruppi dagli ambiti attendibili vengono ottenute dal gestore distribuzione poiché ha accesso a tutte le configurazioni del registro utenti in tutti i domini. Tuttavia, in alcune situazioni non è possibile ottenere informazioni sugli utenti e sui gruppi.

Ad esempio, se viene utilizzato un server ospitato su un nodo esterno localOS come registro per il proprio dominio, il gestore distribuzione non può ottenere le informazioni su utenti e gruppi a meno che non sia in esecuzione nella stessa configurazione del sistema operativo. Per ottenere queste informazioni è necessario contattare il sistema operativo esterno. Questo può essere fatto richiamando direttamente il registro nel server associato a quel dominio. Affinché ciò funzioni, i server associati al dominio devono essere avviati. È inoltre necessario impostare la proprietà,com.ibm.websphere.allowRegistryLookupOnProcess , A VERO nelle proprietà personalizzate di sicurezza di livello superiore. Quando questa proprietà è impostata, il codice del gestore distribuzione ricerca uno dei server associati al dominio di sicurezza e ottiene le informazioni sugli utenti e sui gruppi direttamente da esso. Ciò è possibile richiamando un MBean in uno dei server.

Se non è possibile accedere all'MBean in uno qualsiasi dei server che utilizzano quel dominio, la console di amministrazione visualizza un pannello in cui è possibile inserire l'utente e accessId informazioni manualmente per ciascun utente e gruppo. È importante che sia corretto accessId formato da inserire in questo campo. IL accessId il formato per l'utente èuser:realmName/userUniqueId . IL realmName è il nome dell'area in cui risiede l'utente e il userUniqueId è il uniqueId che rappresenta l'utente, a seconda del registro utilizzato.

Ad esempio, per LDAP, il uniqueUserId è il nome distinto (DN), per Windows localOS registro ed è il SID dell'utente. Per le piattaforme Unix, è l'UID. Per i registri personalizzati, dipende dall'implementazione.

Allo stesso modo, per i gruppi, il accessId il formato è group:realmName/groupUniqueId. Come accennato in precedenza, utilizzare il file listRegistryUsers E listRegistryGroups comandare con il -displayAccessIds opzione impostata su VERO in modo che tu possa ottenere il formato corretto per il dominio o reame che ti interessa.

Una volta che gli utenti e i gruppi provenienti dai regni attendibili o dal AllAuthenticatedInTrustedRealms viene aggiunto un oggetto speciale alla tabella delle autorizzazioni dell'applicazione, è pronta ad accettare richieste da altre applicazioni che utilizzano uno qualsiasi dei suoi ambiti attendibili. La convalida del token LTPA sul server ricevente verifica innanzitutto che il realm sia attendibile. Il motore di autorizzazione verifica quindi se l'utente esterno e/o i gruppi o il fileAllAuthenticatedInTrustedRealms ai soggetti speciali viene concesso l'accesso ai ruoli necessari per accedere alla risorsa. Se vero, l'accesso è concesso.

La comunicazione tra regni è applicabile solo quando si utilizza WebSphere autorizzazione incorporata. Se utilizzi altri motori di autorizzazione, incluso SAF per z/OS, qualsiasi autorizzazione tra regni può essere ottenuta implementando moduli di accesso personalizzati che associano gli utenti esterni agli utenti nel proprio repository.

Federazione di un nodo con domini di sicurezza

Quando un dominio di sicurezza è configurato nella versione di base ed è federato a una cella, il dominio di sicurezza configurato nella versione di base viene configurato anche per quel server nella cella. La stessa configurazione di sicurezza del dominio può essere utilizzata dal server prima e dopo la federazione. Se un server di base deve essere federato a una cella, la risorsa assegnata al dominio di sicurezza dovrebbe essere l'ambito del server anziché l'ambito della cella.

Se si prevede che il server di base venga registrato con un processo dell'agente di gestione, utilizzare l'ambito della cella come risorsa se l'intenzione è che tutti i server nel profilo di base utilizzino questo dominio di sicurezza.

Se durante la federazione il dominio di sicurezza di base esiste già a livello di cella, iladdNode il comando fallisce. Puoi usare - escludere domini di sicurezza opzione per non includere il dominio di sicurezza durante la federazione.

Quando il nodo federato viene rimosso da una cella, le risorse in quel nodo dovrebbero essere rimosse dai domini di sicurezza. Se ai domini di sicurezza sono associati cluster che si estendono su più nodi, i nodi non vengono rimossi. È sempre possibile rimuovere le risorse dai domini di sicurezza o da qualsiasi dominio non utilizzato utilizzando i comandi di script o la console di gestione.

Domini di sicurezza in un ambiente a versione mista

Dovresti creare domini di sicurezza una volta che tutti i nodi sono stati migrati alla versione più recente. Ciò è particolarmente vero se è necessario associare la cella a un dominio. Tuttavia, se desideri creare domini di sicurezza in un ambiente con versioni miste, tieni presente quanto segue:

Modifica dei domini di sicurezza

Utilizzare le attività della console di gestione o i comandi di script per modificare i domini di sicurezza. Per un elenco completo delle attività amministrative e dei comandi di scripting, vedere i collegamenti in "Attività correlate" alla fine di questo documento.

Una volta creato e associato un dominio di sicurezza a un insieme di ambiti, è necessario riavviare i server associati a questo nuovo dominio. Dopo il riavvio, le applicazioni negli ambiti associati al nuovo dominio utilizzano gli attributi di sicurezza definiti nel dominio.

Le modifiche a qualsiasi attributo del dominio richiedono il riavvio di tutti gli ambiti ad esso assegnati. Se vengono aggiunti nuovi ambiti, è necessario riavviarli. Qualsiasi modifica alla configurazione del dominio, sia agli attributi di sicurezza che agli ambiti, ha un impatto sulle applicazioni che utilizzano la configurazione del dominio.

Prima di apportare modifiche a un dominio esistente, considera i seguenti potenziali impatti. Ad esempio, se un registro utenti configurato in un dominio viene rimosso e i server vengono riavviati, verrà utilizzato il registro utenti del dominio a livello di cella (se definito) o la configurazione di sicurezza globale. Ciò può influire sull'autenticazione e sull'autorizzazione dell'applicazione. Gli utenti e i gruppi associati a un'applicazione potrebbero non essere più validi nel nuovo registro. Un altro esempio da considerare è quando JAAS le configurazioni vengono rimosse da un dominio. Le applicazioni che si basano su questo non sono più in grado di utilizzare il file JAAS configurazioni. Ogni volta che viene modificata una configurazione di sicurezza, ciò potrebbe avere un impatto sulle tue applicazioni, pertanto tutte le modifiche alla configurazione di sicurezza devono essere apportate con la massima attenzione.

PTF di tolleranza richieste per ambienti a rilascio misto

Le PTF di tolleranza sono necessarie per ambienti a rilascio misto in cui sono presenti versioni precedenti di WebSphere Application Server per z/OS I client IIOP interagiscono con a WebSphere Application Server Versione 8.5 per z/OS server delle applicazioni che ospita più domini di sicurezza.

Il pre- Versione 8.5 Il client IIOP richiede un aggiornamento al codice di elaborazione della localizzazione IIOP per eseguire le localizzazioni IIOP nei domini di sicurezza di a Versione 8.5 server dell'applicazione.

Le PTF di tolleranza per tutti i service release interessati sono elencate più avanti in questa sezione. Il pre- Versione 8.5 Il client IIOP deve essere pari o successivo al livello di servizio specificato per poter interagire con successo con a Versione 8.5 server delle applicazioni che contiene più domini di sicurezza.

Questo requisito si applica solo a WebSphere per z/OS Client IIOP che richiamano richieste contro a WebSphere per z/OS server delle applicazioni con più domini di sicurezza configurati e abilitati.