Combinazione di modelli di sicurezza

È possibile che vi siano più protocolli e canali negli ambienti di programmazione WebSphere® Application Server Versione 6 e successive. Ognuna di queste applicazioni risponde a diverse esigenze aziendali.

Ad esempio, è possibile accedere a:
  • Un'applicazione basata sul Web attraverso il trasporto HTTP, come servlet, file JavaServer Pages (JSP), HTML e così via.
  • Un'applicazione enterprise tramite RMI (Remote Method Invocation) sul protocollo RMI/IIOP (Internet Inter - ORB).
  • Un'applicazione di servizi Web attraverso il protocollo SOAP over HTTP, SOAP over Java™ Message Service (JMS) o SOAP over RMI/IIOP.

Ancora più importante, i servizi Web sono spesso implementati come servlet con un file EJB (Enterprise JavaBeans ). Pertanto, è possibile combinare e abbinare il modello di sicurezza dei servizi Web con il modello di sicurezza Java Platform, Enterprise Edition (Java EE) per i componenti Web e EJB. Si intende che la sicurezza del servizio Web completa il modello di sicurezza Java EE per i componenti web e EJB. Si intende che la sicurezza del servizio Web completa la sicurezza basata sul ruolo Java EE e il runtime di sicurezza per WebSphere Application Server Versione 6 e successive.

La sicurezza dei servizi Web può inoltre sfruttare le funzioni di sicurezza in Java EE e il runtime di sicurezza per WebSphere Application Server Versione 6 e successive. Ad esempio, la sicurezza dei servizi Web può utilizzare le funzioni di sicurezza riportate di seguito per fornire una distribuzione della sicurezza end - to - end:
  • Utilizza il sistema operativo locale, il protocollo LDAP (Lightweight Directory Access Protocol, LDAP ) e i registri utente personalizzati per l'autenticazione del token nome utente
  • Propaga il token di sicurezza LTPA (Lightweight Third Party Authentication) nel messaggio SOAP
  • Utilizza l'asserzione di identità
  • Utilizzare un TAI (trust association interceptor)
  • Abilita propagazione attributo di sicurezza
  • Utilizzare l'autorizzazione basata sul ruolo Java EE
  • Utilizzare un provider di autorizzazione Java Authorization Contract for Containers (JACC), ad esempio Access Manager di Tivoli®

La seguente figura mostra che vengono utilizzati protocolli di protezione differenti per inviare informazioni di autenticazione al server delle applicazioni. Per un servizio Web, è possibile utilizzare l'autenticazione di base HTTP con Secure Sockets Layer ( SSL ) oppure un token nome utente Web Services Security con firma e crittografia. Nella figura seguente, quando l'identità bob di Web Services Security viene autenticata e impostata come identità del chiamante della richiesta del messaggio SOAP, il contenitore Enterprise JavaBeans di Java EE esegue l'autorizzazione utilizzando bob prima che la chiamata venga inviata all'implementazione del servizio, che in questo caso è il bean enterprise.

Protocollo di sicurezza utilizzato per inviare le informazioni di autenticazione al server delle applicazioni

È possibile proteggere un servizio Web utilizzando la sicurezza del livello di trasporto. Ad esempio, quando si utilizza SOAP su HTTP, è possibile utilizzare HTTPS per proteggere il servizio Web. Tuttavia, la sicurezza del livello di trasporto fornisce solo la sicurezza point - to - point. Questo livello di sicurezza potrebbe essere adeguato per determinati scenari. Tuttavia, quando il messaggio SOAP deve viaggiare attraverso server intermedi (multi - hop) prima che venga utilizzato dall'endpoint di destinazione, è possibile utilizzare SOAP su JMS (Java Message Service). Gli scenari di utilizzo e i requisiti di sicurezza stabiliscono come proteggere i servizi web. I requisiti dipendono dall'ambiente operativo e dalle esigenze aziendali. Tuttavia, un vantaggio fondamentale dell'uso della sicurezza dei servizi Web è che è indipendente dal livello di trasporto; gli stessi vincoli di sicurezza dei servizi Web possono essere usati per SOAP su HTTP, SOAP su JMS o SOAP su RMI/IIOP.