Sicurezza

Basato su standard di settore

IBM WebSphere Application Server fornisce un modello unificato, basato sulle politiche e basato sulle autorizzazioni per proteggere le risorse Web, gli endpoint dei servizi Web e i JavaBeans enterprise in base alle specifiche J2EE . In particolare, WebSphere Application Server è conforme alla specifica Java EE 6 e ha superato la suite di test di compatibilità J2EE .

I modelli di sicurezza standard e le interfacce che supportano la comunicazione socket sicura, la crittografia dei messaggi e la crittografia dei dati sono la Java Secure Socket Extension (JSSE) e la Java Cryptographic Extension (JCE).

Paradigma di architettura aperta

Un server di applicazioni gioca una parte integrante nella framework di calcolo enterprise a più livelli. IBM WebSphere Application Server adotta il paradigma dell'architettura aperta e fornisce molti punti di plugin per integrarsi con i componenti software aziendali. I punti plug-in si basano su specifiche standard J2EE ovunque applicabili.

Lo sfondo ombreggiato di blu scuro indica il limite tra WebSphere Application ServerVersione 9.0 e altri componenti dell'applicazione aziendale.

WebSphere Application Server fornisce SWAM (Simple WebSphere Authentication Mechanism), LTPA (Lightweight Third Party Authentication) e Kerberos come meccanismi di autenticazione. È possibile configurare esattamente un'implementazione del registro utenti in modo che sia il registro utenti attivo del dominio di sicurezza di WebSphere Application Server . WebSphere Application Server fornisce le seguenti implementazioni del registro utenti: UNIX, Windows e IBM i sistema operativo locale e Lightweight Directory Access Protocol ( LDAP ). Fornisce inoltre implementazioni di riferimento per il registro utenti basate su file e sulla connettività database Java ( JDBC ). Supporta una combinazione flessibile di meccanismi di autenticazione e registri utenti. SWAM è semplice da configurare ed è utile per un ambiente server applicativo unico. È possibile utilizzare SWAM in un ambiente distribuito se l'asserzione di identità è abilitata. La funzione di affermazione dell'identità è disponibile solo sul protocollo di sicurezza CSIv2.

Nota: SWAM è stato obsoleto in un precedente rilascio di WebSphere Application Server, e verrà rimosso in una release futura.

Il meccanismo di autenticazione LTPA è progettato per tutte le piattaforme di sicurezza. I server downstream possono convalidare il token di sicurezza. Supporta inoltre l'impostazione di una relazione di associazione di fiducia con server proxy sicuri reverse e SSO (single sign - on), che viene discusso in seguito. Oltre alla combinazione di LTPA e LDAP o all'interfaccia di registrazione utente personalizzata, la versione 6.x o successive supportano LTPA con un'interfaccia di registrazione utente LocalOS. La nuova configurazione è particolarmente utile per un singolo nodo con più server applicativi. Può funzionare in un ambiente distribuito se l'implementazione del registro utenti di OS locale è un registro utenti centralizzato, come Windows Domain Controller, oppure può essere mantenuto in uno stato coerente su più nodi.

WebSphere Application Server supporta l'architettura J2EE Connector e offre l'autenticazione gestita dal contenitore. Fornisce un modulo di mappatura principale di default Java 2 Connector (J2C) che mette in corrispondenza qualsiasi credenziale utente autenticata ad una credenziale di password per il dominio di sicurezza EIS (Enterprise Information Systems) specificato. Il modulo di mappatura è un modulo di login speciale JAAS progettato in base alle specifiche Java 2 Connector e JAAS . Altri moduli di login di mappatura possono essere collegati.

Registri utenti e controllo accessi

Le informazioni relative agli utenti e ai gruppi risiedono in un registro utenti. In WebSphere Application Server, un registro utenti autentica un utente e richiama informazioni su utenti e gruppi per eseguire funzioni relative alla sicurezza, tra cui l'autenticazione e l'autorizzazione.

Oltre a Local OS, LDAP e ai registri di repository federati, WebSphere Application Server fornisce anche un plug-in per supportare qualsiasi registro utilizzando la funzione Registro personalizzato (nota anche come Registro utente personalizzato).

Quando viene scelta l'implementazione del Registro del sistema operativo locale di WebSphere Application Server , consente di integrare la funzionalità del server di sicurezza z/OS , come ad esempio Resource Access Control Facility (RACF), utilizzando direttamente SAF (Security Access Facility) nell'ambiente WebSphere . Se si configura un registro diverso dal sistema operativo locale, è anche possibile usufruire delle funzioni del server di sicurezza z/OS con due opzioni. È possibile configurare un modulo di mappatura JAAS collegabile (seguito da un modulo di login JAAS fornito da WebSphere Application Server for z/OS) nelle configurazioni di login del sistema appropriate. In WebSphere Application Server Versione 8.5, è possibile utilizzare in alternativa la funzione di associazione identità distribuita.

Per ulteriori informazioni, fare riferimento a Selezione di un registro o di un repository.

Configurazioni WebSphere Application Server: con WebSphere Application ServerVersione 9.0 per z/OS è possibile integrare le applicazioni nonz/OS esistenti con funzioni specifiche di z/OScome SAF (System Authorization Facility) e RACF. Ciò consente di unificare i registri per WebSphere Application Server per piattaforme z/OS e nonz/OS . Ad esempio:

Meccanismi di autenticazione

Protocolli di autenticazione IIOP

Il protocollo di autenticazione IIOP si riferisce ai meccanismi utilizzati per autenticare le richieste da un Client Java a un WebSphere Application Server per z/OSo tra J2EE Application Server. Common Secure Interoperability Versione 2 (CSIv2) è implementato in WebSphere Application Server per z/OS Versione 6.x o successivi ed è considerato il protocollo strategico.

WebSphere Application Server per la sicurezza z/OS Connector

WebSphere Application Server supporta l'architettura Connector J2EE e offre autenticazione gestita in container. Fornisce un modulo di mappatura principale e credenziale J2C predefinito che assota qualsiasi credenziale utente autenticata ad una credenziale di password per il dominio di sicurezza EIS (Enterprise Information Systems) specificato. I connettori specifici di z/OSsono supportati anche quando il sistema EIS si trova nello stesso dominio di sicurezza di WebSphere Application Server. In questo caso le password non sono richieste, perché le credenziali autenticate utilizzate per le richieste J2EE possono essere utilizzate come credenziali EIS.

Sicurezza dei servizi web

WebSphere Application Server consente di proteggere i servizi Web basati sulla specifica OASIS (Organization for the Advancement of Structured Information Standards) Web Services Security Versione 1.1 . Questi standard riguardano come fornire protezione per i messaggi scambiati in un ambiente di servizio web. La specifica definisce le strutture di base per proteggere l'integrità e la riservatezza di un messaggio e fornisce meccanismi per associare le rivendicazioni relative alla sicurezza con il messaggio.

Associazioni di fiducia

Propagazione degli attributi di sicurezza

Modalità di interoperabilità single sign-on

In WebSphere Application Server, l'opzione di modalità di interoperabilità consente connessioni SSO (Single Sign - on) tra WebSphere Application Server versione 6.1.x o successive per interoperare con le versioni precedenti del server delle applicazioni. Quando si seleziona questa opzione, WebSphere Application Server aggiunge il vecchio LtpaToken nella risposta in modo che possa essere inviato ad altri server che utilizzano solo questo tipo di token. Questa opzione si applica solo quando l'opzione di propagazione dell'attributo di sicurezza in entrata web è abilitata. Per ulteriori informazioni su single sign - on, fare riferimento a Riferimento singolo di esecuzione per minimizzare le autenticazioni degli utenti web

Sicurezza per le risorse J2EE che utilizzano contenitori web e contenitori per gli EJB

Ogni contenitore fornisce due tipi di sicurezza: Sicurezza dichiarativa e sicurezza programmatica. Nella sicurezza dichiarativa, la struttura di sicurezza di un'applicazione, tra cui l'integrità e la riservatezza dei dati, i requisiti di autenticazione, i ruoli di sicurezza e il controllo degli accessi, è espressa in un modulo esterno all'applicazione. In particolare il descrittore di distribuzione è il veicolo principale per la sicurezza dichiarativa nella piattaforma J2EE . WebSphere Application Server conserva una policy di sicurezza J2EE , incluse le informazioni derivate dal descrittore di distribuzione e specificate da distribuzioni e amministratori in una serie di file descrittori XML. In fase di esecuzione, il contenitore utilizza la politica di sicurezza definita nei file descrittori XML per far rispettare i vincoli di dati e il controllo degli accessi. Quando la sola sicurezza dichiarativa non è sufficiente per esprimere il modello di sicurezza di un'applicazione, il codice applicativo può utilizzare la sicurezza programmatica per prendere decisioni di accesso. L'API (application programming interface) per la sicurezza programmatica è costituita da due metodi dell'interfaccia EJB (Enterprise JavaBeans ) EJBContext (isCallerInRole,getCallerPrincipal) e tre metodi dell'interfaccia servlet HttpServletrequest (isUserInRole,getUserPrincipal,getRemoteUser).

Sicurezza Java 2

WebSphere Application Server supporta il modello di sicurezza Java 2. I codici di sistema come il sottosistema di gestione, il contenitore web e il contenitore EJB, sono in esecuzione nel dominio di sicurezza WebSphere Application Server , che nella presente implementazione sono concessi con AllPermission e possono accedere a tutte le risorse di sistema. Il codice dell'applicazione in esecuzione nel dominio di sicurezza dell'applicazione, che per impostazione predefinita è concesso con autorizzazioni in base alle specifiche J2EE , può accedere solo ad una serie limitata di risorse di sistema. WebSphere Application Server le classi di runtime sono protette dal programma di caricamento classi WebSphere Application Server e non sono visibili al codice dell'applicazione.

Piattaforma Java 2 Platform, Enterprise Edition Connector

WebSphere Application Server supporta l'architettura Connector J2EE e offre autenticazione gestita in container. Fornisce un modulo di mappatura principale e credenziale J2C predefinito che assota qualsiasi credenziale utente autenticata ad una credenziale di password per il dominio di sicurezza EIS (Enterprise Information Systems) specificato.

I connettori specifici di z/OSsono supportati anche quando il sistema EIS si trova nello stesso dominio di sicurezza di WebSphere Application Server. In questo caso le password non sono richieste, perché le credenziali autenticate utilizzate per le richieste J2EE possono essere utilizzate come credenziali EIS.

Per ulteriori informazioni fare riferimento a Identità thread di connessione.

Tutti i processi del server delle applicazioni, per impostazione predefinita, condividono una configurazione di sicurezza comune, definita in un documento XML di sicurezza a livello cellulare. La configurazione di sicurezza determina se la sicurezza WebSphere Application Server viene applicata, se viene applicata la sicurezza Java 2, il meccanismo di autenticazione e la configurazione del registro utenti, le configurazioni del protocollo di sicurezza, le configurazioni di login JAAS e le configurazioni Secure Sockets Layer. Le applicazioni possono avere i propri requisiti di sicurezza unici. Ciascun processo del server delle applicazioni pu creare una configurazione di sicurezza per server per soddisfare i propri requisiti di sicurezza o per essere associato a un dominio di sicurezza WebSphere . Non tutte le configurazioni di sicurezza possono essere modificate a livello di server delle applicazioni. Alcune configurazioni di sicurezza che possono essere modificate a livello di server delle applicazioni includono se la sicurezza delle applicazioni deve essere applicata, se la sicurezza Java 2 deve essere applicata e le configurazioni del protocollo di sicurezza. WebSphere i domini di sicurezza consentono un maggiore controllo sulla configurazione della sicurezza e possono essere associati a singoli server. Leggi su Più domini di sicurezza per ulteriori informazioni.

Per ulteriori informazioni generali fare riferimento a Stati di sicurezza con supporto di identità thread.

La configurazione di sicurezza del sottosistema amministrativo è sempre determinata dal documento di sicurezza del livello cellulare. Il contenitore web e la configurazione della sicurezza del contenitore di tipo EJB sono determinati dal documento di sicurezza del livello di server opzionale, che ha la precedenza sul documento di sicurezza a livello cellulare.

La configurazione di sicurezza, sia a livello di cella che a livello di server delle applicazioni, sono gestite sia dall'applicazione della console di gestione basata sul Web sia dall'apposita applicazione di scripting.

Nota: Non è possibile modificare i meccanismi di autenticazione a livello server.

Sicurezza Web

Su WebSphere Application Server, il registro utenti di OS locale non supporta la funzione di mappatura.

Quando il meccanismo di autenticazione LTPA è configurato e SSO (single sign - on) è abilitato, un client autenticato viene emesso un cookie di sicurezza, che può rappresentare l'utente all'interno del dominio di sicurezza specificato.

Si consiglia di utilizzare Secure Sockets Layer ( SSL ) per proteggere il cookie di sicurezza o le informazioni di autenticazione di base dall'intercettazione e dalla riproduzione. Quando viene configurata un'associazione di trust, WebSphere Application Server può mappare un'identità utente autenticata alle credenziali di sicurezza in base alla relazione di trust stabilita con il server proxy inverso sicuro.

Sicurezza degli EJB

Quando la sicurezza è abilitata, il contenitore dell'EJB enfatizza l'accesso al metodo di richiamo del metodo EJB. L'autenticazione avviene indipendentemente dal fatto che venga definita un'autorizzazione di metodo per il metodo specifico dell'EJB.

Un client di applicazioni Java può fornire i dati di autenticazione in diversi modi. Utilizzare l'opzionesas.client.propsfile, un client Java può specificare se utilizzare un ID utente e una password per l'autenticazione o un certificato client SSL per l'autenticazione. Il certificato client viene memorizzato nel file chiave o nella scheda crittografica hardware, come definito in unsas.client.props.xlsx. L'ID utente e la password possono essere facoltativamente definiti nellasas.client.props.xlsx.

In fase di esecuzione, il client Java può eseguire un login programmatico o eseguire un'autenticazione lazy.

Nell'autenticazione laica quando il client Java accede ad un bean enterprise protetto per la prima volta, il tempo di esecuzione della sicurezza cerca di ottenere i dati di autenticazione richiesti. A seconda dell'impostazione di configurazione insas.client.propsfile il runtime di sicurezza esamina i dati di autenticazione da questo file o ne richiede l'utente. In alternativa, un client Java può utilizzare il login programmatico. WebSphere Application Server supporta il modello di programmazione JAAS e il login JAAS (LoginContext) è il modo consigliato di login programmatico. La funzione helper login_helper request_login è obsoleta nella Versione 6.x e Versione 9.0. I client Java programmati a login_helper APT possono essere eseguiti in questa versione.

Il collaboratore di sicurezza degli EJB enfatizza il controllo degli accessi basato sul ruolo utilizzando un'implementazione del gestore di accesso.

Un gestore di accesso rende le decisioni di autorizzazione basate sulla politica di sicurezza derivate dal descrittore di distribuzione. Un principal utente autenticato può accedere al metodo EJB richiesto se ha uno dei ruoli di sicurezza richiesti. Il codice EJB può utilizzare i metodi EJBContext isCallerInRole e getCallerPrincipal. Il codice EJB può anche utilizzare il modello di programmazione JAAS per eseguire i metodi JAAS login e WSSubject doAs e doAsPrivileged. Il codice nei blocchi doAs e PrivilegedAction viene eseguito sotto l'identità del soggetto. Altrimenti, il metodo EJB viene eseguito sotto l'identità RunAs o l'identità del chiamante, a seconda della configurazione RunAs. La specifica J2EE RunAs è a livello di enterprise bean. Quando si specifica l'identità RunAs, questa si applica a tutti i metodi del bean. L'estensione IBM RunAs a livello di metodo introdotta nella versione 4.0 è ancora supportata in questa versione.

Nota: una volta eseguita l'autorizzazione, l'identità RunAs viene utilizzata a valle. Questa è tipicamente l'identità del chiamante ma può anche essere un'identità delegata.

Standard di elaborazione delle informazioni federali - approvato

Le Norme federali di elaborazione delle informazioni (FIPS) sono norme e linee guida emanate dal National Institute of Standards and Technology (NIST) per i sistemi informatici federali. I FIPS sono sviluppati quando ci sono requisiti di governo federali avvincenti per gli standard, come per la sicurezza e l'interoperabilità, ma gli standard o le soluzioni di settore accettabili non esistono.

WebSphere Application Server integra moduli crittografici tra cui Java Secure Socket Extension (JSSE) e Java Cryptography Extension (JCE), che hanno subito la certificazione FIPS 140 - 2.

Per ulteriori informazioni, fare riferimento a Configurazione dei file di estensione Java Secure Socket Standard.

Il modulo crittografico IBMJCEFIPS contiene gli algoritmi che sono approvati da FIPS, che formano un corretto sottoinsieme di quelli presenti nei moduli IBM JCE.