Introduzione
In [MOKA_INT2] si è visto come l'integrazione Object/RPC consenta l'invocazione remota dei metodi degli oggetti distribuiti (EJB, CORBA, DCOM, …). Si è visto come sia possibile utilizzare RMI-IIOP al posto dei vari protocolli proprietari (JNP di JBoss o T3 di Weblogic, …) in modo da permettere la comunicazione in modo interoperabile (ossia vendor independent).
In particolare si è visto in [MOKA_INT3] come, esportando un EJB con protocollo IIOP, sia possibile invocarlo da un client Java che utilizza l'ORB Jacorb (vedere[JACORB]) oppure l'ORB Sun o anche da un client CORBA C++ che utilizza l'ORB MICO (vedere [MICO]).
Il servizio di business utilizzato nell'esempio è costituito da un semplice EJB Session Stateless Calculator che espone il seguente metodo di business:

public interface Calculator extends EJBObject {
public int getStringLength(String a) throws RemoteException;
}

con le seguente semplice implementazione che ritorna la lunghezza della stringa ricevuta come parametro:

public int getStringLength(String a) {
return a.length();
}

Con la versione 3.2.x di JBoss (che integra l'ORB di JacORB) per esportare un EJB in IIOP bisogna specificare nel file DD l'attributo <invoker-proxy-binding-name> con valore iiop.

<session>
<ejb-name> CalculatorBean </ejb-name>
<jndi-name> MokaCalculator </jndi-name>
<configuration-name>Standard Stateless SessionBean</configuration-name>
<invoker-bindings>
<invoker>
<invoker-proxy-binding-name>iiop</invoker-proxy-binding-name>
</invoker>
</invoker-bindings>
</session>

Il client Java per invocare l'EJB crea un contesto JNDI, effettua la lookup e narrow della Home interface, crea una Remote interface per poi invocare il metodo di business getStringLength():

public class CalculatorTestClient {
. . . . .
public void test(String jndiName) {
try {
Context ctx = new InitialContext();
//look up jndi name
Object ref = ctx.lookup(jndiName);
Object obj = PortableRemoteObject.narrow(ref, CalculatorHome.class);
CalculatorHome home = (CalculatorHome) obj;
Calculator calculator = home.create();
System.out.println("Risultato: " + calculator.getStringLength("Ciao a tutti!"));
……

Il client può quindi localizzare l'EJB mediante IIOP specificando le seguenti proprietà JNDI:

• java.naming.factory.initial=com.sun.jndi.cosnaming.CNCtxFactory
• java.naming.provider.url= corbaloc:iiop:<<SERVER>>:3528/JBoss/Naming/root

Con queste proprietà impostate, il client potrà utilizzare le API JNDI come un Wrapper per accedere al servizio di CORBA Naming Service fornito dal server che si desidera contattare.
Per quanto riguarda l'implementazione di ORB utilizzata, per default il client utilizza l'implementazione ORB di SUN del J2SDK: la classe com.sun.corba.se.internal.iiop.ORB.

E' però possibile fare in modo che il client utilizzi un diverso ORB impostando le proprietà org.omg.CORBA.ORBClass e org.omg.CORBA.ORBSingletonClass.
Ad esempio per utilizzare l'ORB di JacORB (sempre a parità di bytecode!) si deve includere nel classpath il jar di JacORB e specificare le seguenti proprietà:

• Dorg.omg.CORBA.ORBClass=org.jacorb.orb.ORB
• Dorg.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORBSingleton

Per effettuare la prova con Jacorb è inoltre necessario configurare il Security Manager sul client specificando le proprietà di sicurezza java.security.manager e java.security.policy al fine di permettere al network classloader lo scaricamento degli stub (di default il network classloader è disabilitato causando un ClassCastException con il PortableRemoteObject.narrow())

Oltre a consentire l'interoperabilità tra client Java che utilizzano l'ORB Sun o l'ORB Jacorb, i benefici dell'utilizzo di IIOP si sono visti in modo chiaro utilizzando un client C++ che, mediante l'ORB MICO, è in grado di comunicare con l'EJB Calculator installato su JBoss.

Figura 1: Interoperabilità IIOP

L'esempio che si è fin qui richiamato, che sintetizza quanto descritto in [MOKA_INT3] non prende in considerazione alcuna istanza di sicurezza nella comunicazione fra il client e l'oggetto remoto: si assume infatti che il livello di sicurezza sia a monte dell'EJB e che le interazioni fra oggetti Corba avvengano entro un ambiente protetto da intrusioni e intercettazioni da parte di estranei.
Generalmente per fare questo si installa un Firewall in ingresso al sistema con un'unica porta aperta (la porta 80) del Web Server e si utilizza il protocollo HTTPS per la comunicazione tra la zona demilitarizzata e la zona sicura.

In questo modo l'EJB potrà essere utilizzato solo da una risorsa Web previa opportuna autenticazione e autorizzazione.

Figura 2: Sicurezza lato Web

In questo scenario dunque, gli EJB sono esposti esclusivamente all'interno della Zona Privata, che è quindi sicura. Tuttavia, potrebbe esserci la necessità di rendere accessibili direttamente gli EJB (ad esempio per comunicazioni B2B) o avere esigenze di proteggere l'accesso ad alcuni EJB da usi impropri e/o fraudolenti che potrebbero provenire dall'interno della stessa Zona Privata o da eventuali violazioni della sicurezza a monte.

Figura 3: Scenario B2C e B2B

Per venire incontro a queste esigenze, è necessario dotare il protocollo IIOP di un livello di sicurezza.
Introduzione a IIOP/SSL

Fino a qualche anno fa, non esistevano standard che permettessero interoperabilità sicura nel mondo CORBA e tanto meno quando fossero coinvolti componenti EJB. Da un po' di tempo la situazione è fortunatamente più chiara: per quanto riguarda il mondo CORBA, esiste oggi una specifica denominata Common Secure Interoperability (CSI) che definisce precisi livelli di conformità dei vari vendor ai requisiti di interoperabilità sicura. Tale specifica è giunta ora alla seconda versione (denominata CSIv2) ed è descritta nella specifica ufficiale di CORBA 3.02 (vedere [CORBA3.02_SPEC] Capitolo 24). CSIv2 prevede 3 livelli di conformità, che i vari vendor possono supportare: dal livello zero (CVIv2Lev0) che è quello meno stringente in quanto pone meno requisiti e supporta meno funzionalità, fino al livello 2 che è il più ricco e completo (vedere [DF_CSIV2]). Semplificando molto, troviamo:

• CSIv2- Lev. 0 prevede il solo supporto all'interoperabilità sicura senza alcun meccanismo di delega
• CSIv2- Lev. 1 richiede anche il supporto alla delega, ma senza possibilità di imporre restrizioni al potere di delega che si conferisce
• CSIv2- Lev. 2 infine prevede oltre a quanto richiesto dal Livello 1 anche il supporto per un controllo più fine del potere di delega che si conferisce

Per spiegare il meccanismo della delega dei privilegi, facciamo riferimento ad un esempio. Supponiamo di avere un oggetto client che invoca, un oggetto Intermediate che infine invoca e infine un oggetto target. L'oggetto client si presenterà all'intermediate con le proprie credenziali (identità, password, certificati...). Quando l'Intermediate invoca a sua volta l'oggetto Target può presentarsi con le proprie credenziali (e in questo caso vuol dire che non si sta utilizzando la delega) oppure può presentarsi con le credenziali del client (in tutto o in parte) e questo richiede che il client gli abbia delegato le proprie credenziali.

E' importante osservare che la conformità al supporto CSIv2 - almeno al livello 0 - è un requisito delle specifiche J2EE a partire dalla versione 1.3 (vedere [EJB2.0] - par 19.8.2). Quindi un AS certificato conforme a J2EE 1.3 deve fornire il supporto per l'interoperabilità sicura in conformità alle specifiche CSIv2.

Esistono due architetture di protocolli che consentono di introdurre i requisiti di sicurezza nelle transazioni IIOP:

• SSLIOP: utilizza SSL/TLS come trasporto sicuro in luogo del semplice trasporto TCP. E' oggi l'approccio maggiormente utilizzato.
• SECIOP: è più complesso, ma più versatile in quanto può utilizzare diversi meccanismi di sicurezza (GSS-UP / Kerberos / ECMA-CSI).

In ambedue i casi, al di sopra del layer di trasporto sicuro, CSIv2 prevede in aggiunta un servizio Corba apposito denominato SAS (Secure Attribute Service) che consente di definire e trasmettere tra oggetti Corba informazioni inerenti le credenziali, i privilegi, i ruoli ecc. Tale servizio ha anche lo scopo di supplire ad eventuali deficienze del trasporto sicuro (ad esempio: SSL non prevede - come vedremo presto - la possibilità che sia il client a richiedere obbligatoriamente la propria autenticazione.
La nostra trattazione e le prove pratiche che eseguiremo si concentreranno sull'uso di SSLIOP.
Introduzione a SSL.
SSL è un protocollo che fornisce uno strato di estensioni alla suite standard TCP/IP in modo da aggiungere funzionalità inerenti la sicurezza.
Nello schema che descrive lo stack di protocolli della suite, il livello Secure Socket Layer (SSL) occupa il posto compreso tra il trasporto standard TCP (affidabile ma non "sicuro") ed il livello applicativo (HTTP, NNTP, LDAP,…).

Figura 4 : TCP/IP Stack & SSL

Le problematiche di sicurezza affrontate in SSL sono le seguenti:

• Riservatezza: Evitare che estranei possano leggere il contenuto della trasmissione
• Autenticazione: ovvero come avere la garanzia che la controparte con cui si interagisce sia effettivamente chi dichiara di essere
• Integrità del messaggio: evitare che un attacker possa modificare il contenuto della trasmissione

Per raggiungere i tre obiettivi sopra descritti, SSL si avvale di altrettanti meccanismi:

• La Crittografia a chiave segreta (o simmetrica): viene impiegata per ottenere la privacy nella comunicazione. Possono essere utilizzati diversi algoritmi quali ad esempio DES o RC4 (vedere [SEC_ALG]).
• La Crittografia a chiave pubblica (o asimmetrica): viene utilizzata al duplice scopo di ottenere un canale sicuro attraverso il quale permettere lo scambio della chiave segreta di sessione e per permettere l'autenticazione delle controparti.
• Funzioni di Hash sicure: quali MD5, SHA, vengono impiegate per calcolare una sorta di checksum sul messaggio da trasmettere denominato Message Authentication Code (MAC). Il MAC viene trasmesso contestualmente al messaggio; il ricevente ricalcola il MAC e lo confronta con quello trasmesso: se si rileva una differenza, il messaggio è stato manomesso (tampered).

Autenticazione
Per quanto riguarda le problematiche di autenticazione, bisogna distinguere tra

• Autenticazione del Target
• Autenticazione del Client

L'autenticazione del target, nell'utilizzo classico di SSL (ad esempio, abbinato con HTTP nelle applicazioni Web: HTTPS) è quella che riveste la maggior importanza ed interesse. Si tratta della possibilità di essere certi che quando si invoca un Server Remoto (il Target) chi ci risponde sia effettivamente quello che ci aspettiamo. Si pensi ad esempio ad un Sito Web di eCommerce: alla fine della transazione di acquisto il server ci richiederà verosimilmente il numero di carta di credito ed ovviamente noi (il client) vogliamo essere certi che questi nostri dati sensibili non finiscano in mano di malintenzionati.
L'autenticazione del client invece assomiglia di più al caso classico del problema della login: ossia accertarsi che il client che richiede un certo servizio da un Server remoto sia riconosciuto da questo come un'entità autorizzata a fruirne. Nel caso delle applicazioni WEB, questo scenario si incontra quando si vuole riservare l'accesso ad una zona particolare di un Sito soltanto a particolari client (i Browser in possesso delle opportune credenziali).
Sicuramente in uno scenario di comunicazioni diretta fra oggetti (Business to Business - B2B) possono essere rilevanti ambedue le tipologie di problema, autenticazione del target e del client, cioè una mutua autenticazione.

Handshake SLL
Nella figura 5 si riporta lo schema dell'handshake del protocollo SSL.

Figura 5: Handshake SSL

Esaminiamo rapidamente questo schema soffermandoci sui passaggi più rilevanti.
I primi due messaggi scambiati, denominati 'hello' (messaggio '1' e '2'), permettono a client e target di stabilire l'accordo sulle feature di sicurezza. Attraverso questi messaggi vengono concordate la versione di protocollo, il session ID, la suite di cifratura impiegata ed il metodo di compressione.
Successivamente (messaggio '3') il server invia il proprio Certificato. Questo passo è segnato come opzionale perché non in tutte le interazioni SSL è necessariamente mandatoria l'Autenticazione del Target.
Analogamente al passo '7' vediamo il client inviare il proprio certificato: anche questo passo può essere omesso, qualora non sia prevista l'autenticazione del client. Nel caso di SSL, è sempre e solo il Target che decide se sia necessario o meno richiedere l'autenticazione del client: se questa è richiesta, il target emette il messaggio 4 (Request Client Certificate) ed il client dovrà a sua volta inviare il proprio certificato per permettere al Target di autenticarlo.

Crittografia a chiave pubblica in SSL
Come si è accennato, il protocollo SSL si basa su un'infrastruttura a chiave pubblica (PKI) per il duplice scopo di autenticare le controparti e permettere lo scambio sicuro delle chiavi di sessione. Questo meccanismo prevede che ogni partecipante alla comunicazione si doti di una coppia di chiavi, distinte ma correlate: una pubblica ed una privata. La chiave privata viene tenuta gelosamente custodita e mai rivelata ad estranei; viceversa, la chiave pubblica corrispondente può - anzi deve - essere liberamente distribuita. Una caratteristica comune a molti algoritmi a chiave pubblica (ad esempio RSA) è che i messaggi crittografati con la chiave pubblica possono essere decrittati solo con la chiave privata corrispondente e viceversa. Vedremo ora attraverso degli esempi che in effetti per ottenere la riservatezza del canale di trasmissione si adopera la chiave pubblica per crittografare il messaggio e la privata per decrittarli. Ma vedremo anche che grazie alla proprietà di simmetria sopra citata, la chiave privata può essere usata per asserire la propria identità e la corrispondente chiave pubblica per verificarla.
Esamineremo in particolare tre scenari che dimostrano separatamente gli impieghi della PKI che avvengono in modo combinato nelle interazioni SSL.

Riservatezza (senza autenticazione)
Supponiamo che due controparti Alice e Bob debbano scambiare un messaggio in modo sicuro. Ciascuno avrà la propria coppia di chiavi pubblica e privata. Quando Alice vuole trasmettere un messaggio a Bob, usa la chiave pubblica di Bob (liberamente accessibile), codifica con essa il messaggio e lo trasmette. Quando Bob riceve il messaggio, userà la propria chiave privata per leggerlo. Poiché solo Bob possiede la sua chiave privata, nessun altro potrà aver letto il messaggio. Con questo meccanismo si è così conseguito un canale che tutela la riservatezza delle informazioni trasmesse. Il motivo per cui in SSL non si crittografino tutti i messaggi con questo meccanismo ma venga usato solo per scambiare le chiavi di sessione è dovuto alla sua relativa pesantezza dal punto di vista computazionale. E' quindi conveniente adottare la cifratura simmetrica (ossia basata su un'unica chiave segreta concordata tra le parti) per cifrare in modo efficiente i messaggi.
Per combinare il meccanismo di cifratura a chiave pubblica con quello a chiave simmetrica. Bob dovrà procedere in questo modo:

1. Preparare il messaggio
2. cifrare il messaggio con le tecniche di cifratura simmetrica attraverso una chiave di sessione usata una sola volta
3. cifrare la chiave di sessione con la chiave pubblica di Alice
4. accludere la chiave di sessione cifrata al messaggio ed inviare il tutto ad Alice

Figura 6: Riservatezza (senza autenticazione)

Autenticazione (senza riservatezza)
Vedremo ora una diversa modalità di utilizzo della PKI, volta allo scopo di dare garanzia all'interlocutore della nostra identità. Supponiamo quindi che Bob voglia inviare ad Alice un messaggio volendo assicurare Alice che il mittente è proprio lui e non un impostore. Tale messaggio potrebbe essere letto anche da altri utenti della rete per cui non dovrà contenere dati sensibili. In questo scenario Bob spedirà ad Alice due copie di tale messaggio: una in chiaro ed una crittografata con la propria chiave privata. Quando Alice riceve il messaggio, decifra la parte crittografata utilizzando la chiave pubblica di Bob: se ritrova il messaggio in chiaro inviato, dedurrà che il mittente non può essere stato che Bob, in quanto nessun altro avrebbe potuto cifrarlo in quel modo, non possedendo la sua chiave privata. Quindi, il messaggio in chiaro, abbinato a quello codificato con la chiave privata, funge da firma digitale. Così si è visto in questo scenario come la PKI possa essere impiegata per verificare l'identità di una controparte.

Figura 7: Autenticazione (senza riservatezza)

Distribuzione delle chiavi pubbliche
Resta ora da risolvere un problema pratico: come fa Alice ad entrare in possesso della chiave pubblica di Bob? Il metodo più sicuro sarebbe certamente che sia Bob stesso a consegnarla ad Alice di persona, ma di certo questa strada non è affatto pratica e per di più presuppone che Alice sia in grado di riconoscere Bob (il che non è sempre possibile o meglio richiede un ulteriore meccanismo di verifica dell'identità). Un ulteriore difficoltà è data dal fatto che se Alice desidera comunicare con molte controparti, dovrà dotarsi di un archivio di chiavi pubbliche considerevole, ciascuna delle quali le sarà stata fornita dal rispettivo interlocutore. Un tale vasto archivio di chiavi pubbliche rappresenta un problema di gestione notevole anche perché un'entità che oggi è considerata fidata può non esserlo più domani.
La soluzione a queste difficoltà risiede ancora una volta nell'utilizzo della crittografia a chiave pubblica: Bob provvede a spedire, nel corso dello handshake SSL, la propria chiave pubblica entro un apposito messaggio detto certificato che sarà stato siglato con la firma digitale di una Certification Authority (CA) quale Verisign e serve appunto ad attestare la bontà della chiave pubblica contenuta Queste CA sono entità fidate e riconosciute a livello internazionale e le loro public Key sono normalmente preinstallate nei pacchetti software che utilizzano SSL (ad esempio i Browser Internet). Nella terminologia di SSL, un repository di chiavi pubbliche viene denominato trustStore, in quanto possedere la chiave pubblica di qualcuno vuol dire in sostanza ritenere fidata (trusted) quella controparte. La JVM per default utilizza come trustore contenente le chiavi pubbliche delle CA il file %JAVA_HOME%\jre\lib\security\cacerts.
Quindi Alice è in grado di riconoscere che la firma digitale apposta al certificato proviene da una CA ed è pertanto attendibile. Poiché la CA è fidata, Alice può contare sulla bontà della chiave pubblica contenuta nel certificato.
In definitiva, i certificati rappresentano un modo pratico per distribuire le chiavi pubbliche. Il formato dei certificati utilizzati nella pratica è descritto nella raccomandazione X.509 (vedere [RFC_X509]).

Certificati selfsigned
In generale, i certificati firmati dalle CA si pagano. La procedura di acquisto comporta una verifica diretta dell'identità dell'acquirente da parte della Certification Authority. Benché sia possibile ottenere gratuitamente un certificato di prova da una CA per un periodo limitato abbiamo preferito basare le nostre prove creando dei certificati selfsigned. Con questo meccanismo, chiaramente adatto solo alla sperimentazione e non alle situazioni reali, il possessore della chiave pubblica fa anche le veci della CA e firma il suo stesso certificato. Per quanto abbiamo detto, questa configurazione richiede che, chi vuole interoperare con il possessore di un certificato selfsigned, dovrà specificare un truststore alternativo che comprenda la chiave pubblica corrispondente, in modo da considerarlo alla stregua di una CA.

Figura 8: Creazione certificate con keytool JDK

Abilitare IIOP/SSL su JBoss
Vediamo quindi quali sono gli step necessari per abilitare il trasporto sicuro SSL nell'esposizione di un EJB con JBoss (vedere [JBOSS]). Ovviamente, si farà riferimento alla Server Configuration 'all' di JBoss che è quella che contiene il supporto per l'esposizione attraverso IIOP e quindi i necessari file di configurazione per poter abilitare anche il supporto a IIOP/SSL (vedere [MOKA_INT_3]).
Innanzi tutto è bene precisare che le operazioni necessarie per abilitare l'SSL non richiedono nessuna modifica a livello di sorgente Java.
Vediamo i passi salienti per esporre l'EJB Calculator in modo sicuro con JBoss (verranno descritti in modo dettagliato nel prossimo articolo).
Come primo passo bisogna editare il file <<JBOSS_HOME>>/server/all/deploy/iiop-service.xml e scommentare le sezioni specificate all'inizio del file per abilitare il supporto SSL: si tratta innanzitutto di scommentare l'MBean JaasSecurityDomain

<!-- (uncomment to use IIOP over SSL)
-->
<mbean code="org.jboss.security.plugins.JaasSecurityDomain"
name="jboss.security:service=JaasSecurityDomain,domain=IIOP+SSL">
<constructor>
<arg type="java.lang.String" value="IIOP+SSL"/>
</constructor>
<attribute name="KeyStoreURL">YOURKEYSTORE</attribute>
<attribute name="KeyStorePass">YOURKEYSTOREPASS</attribute>
</mbean>

Al posto delle stringhe YOURKEYSTORE, YOURKEYSTOREPASS, dovrete inserire ri-spettivamente un URL che punti al file di keystore che il server dovrà utilizzare e la relativa password che nel nostro caso sono rispettivamente
'file://C:/mokabyte/moka_iiop_over_ssl/cert/trust_in_target/mokakeystore.ks'e 'alberto'.

Configurato il keystore, si deve procedere a scommentare l'attributo 'SecurityDomain' ed il relativo elemento innestato 'depends' presente nel MBean CorbaORBService nello stesso file

<mbean code="org.jboss.iiop.CorbaORBService"
name="jboss:service=CorbaORB">
<attribute name="ORBClass">org.jacorb.orb.ORB</attribute>
<attribute name="ORBSingletonClass">org.jboss.system.ORBSingleton</attribute>
<attribute name="ORBSingletonDelegate">org.jacorb.orb.ORBSingleton</attribute>
<attribute name="ORBPropertiesFileName">jacorb.properties</attribute>
<attribute name="PortableInterceptorInitializers">
<interceptor-initializers>
<initializer>org.jboss.iiop.codebase.CodebaseInterceptorInitializer</initializer>
</interceptor-initializers>
</attribute>
<!-- (uncomment to use IIOP over SSL)
-->
<attribute name="SecurityDomain">java:/jaas/IIOP+SSL</attribute>
<depends>jboss.security:service=JaasSecurityDomain,domain=IIOP+SSL</depends>
</mbean>

Come secondo passo bisogna editare il file <<JBOSS_HOME>>/server/all/conf/jacorb.properties che contiene i settaggi dell'ORB Jacorb integrato in JBoss.
Dovrete anzitutto impostare la property:

jacorb.security.support_ssl=on (per default è impostata a off)

Poi bisognerà impostare le property seguenti o con valore 20 (EstablishTrustInTarget-Autenticazione del Target), 40 (EstablishTrustInClient-Autenticazione del Client) e 60 (mutual authenticationmutua autenticazione).

Es:
jacorb.security.ssl.client.supported_options=20
jacorb.security.ssl.client.required_options=0
jacorb.security.ssl.server.supported_options=20
jacorb.security.ssl.server.required_options=20

Adesso che è stata attivata la "protezione" sul Server, proviamo quindi a vedere se i client Java utilizzati in precedenza con l'Application Server senza SSL, riescono a collegarsi nuovamente all'Application Server che ha l'SSL abilitato.
Il client fallisce perché il proprio truststore non contiene la chiave pubblica del server contattato. Non è quindi in grado di riconoscere il certificato fornito dal server come valido e pertanto non accetta il dialogo con l'oggetto target.
(org.omg.CORBA.NO_PERMISSION: vmcid: 0x0 minor code: 3 completed: No).

Figura 9: Comunicazione senza certificati

Bisogna quindi procedere a installare e configurare l'opportuno certificato sul client in modo tale che l'handshake SSL vada a buon fine.

Per indicare al client si dovrà prendere il certificato contenuto pub_mokakeystore.ks mediante le proprietà javax.net.ssl.trustStore:

-Djavax.net.ssl.trustStore=C:/mokabyte/moka_iiop_over_ssl/cert/pub_mokakeystore.ks

Lanciando il client otteniamo che la comunicazione avviene con successo.

Figura 10: Comunicazione con certificati

Conclusioni
In questo articolo si è parlato di come sia possibile comunicare con oggetti remoti mediante il protocollo sicuro SSLIOP.
Nel prossimo articolo verranno esemplificati i concetti fino ad ora spiegati.

Bibliografia
[MOKA_INT1] S.Rossini: Integrazione di applicazioni Enterprise (I) MokabyteN.71-Aprile 2003
[MOKA_INT2] S.Rossini: Integrazione di applicazioni Enterprise (II) MokabyteN.72-Maggio 2003
[MOKA_INT3] S.Rossini, A. D'Angeli: Integrazione di applicazioni Enterprise (III) Moka-byte N.73-Giugno 2003
[MOKA_INT4] S.Rossini: Integrazione di applicazioni Enterprise (IV) MokabyteN.74-Luglio/Agosto 2003
[MOKA_INT5] S.Rossini, A. D'Angeli: Integrazione di applicazioni Enterprise (V) Moka-byteN.74-Settembre 2003
[MOKA_INT6] S.Rossini : Integrazione di applicazioni Enterprise (VI) MokabyteN.83-Marzo 2004
[MOKA_IIOP-1] S. Rossini: "RMI-IIOP I parte", Mokabyte N.44, Settembre 2000
[MOKA_IIOP-2] S. Rossini: "RMI-IIOP II parte", Mokabyte N.45, Ottobre 2000
[MOKA_IIOP-3] G. Puliti: "RMI over IIOP", Mokabyte N.70, Gennaio 2003
[CORBA3.02_SPEC] http://www.omg.org/technology/documents/corba_spec_catalog.htm
[DF_CSIV2] Don Flinn: CSIv2 Presentation
http://www.omg.org/news/meetings/workshops/presentations/
docsec_2001_present/3-3%20Flinn%202_CSIv2.pdf
[SSL_SPEC] SSL 3.0 SPECIFICATION: http://wp.netscape.com/eng/ssl3
[MODSSL] http://www.modssl.org/docs/2.8/ssl_intro.html
[EJB-2.0] http://java.sun.com/products/ejb/docs.html
[SEC_ALG] http://www.ssh.fi/support/cryptography/algorithms
[RFC_X509] RFC 2459 - Internet X.509 Public Key Infrastructure Certificate and CRL Profile
[JBOSS] http://www.jboss.org
[JACORB] http:// www.jacorb.org