Implementazione e protezione di Web Services con Oc4j ed Axis

Con questo articolo vogliamo descrivere come rendere disponibili tramite Web Services i metodi di una applicazione enterprise. Mostreremo anche come proteggerli tramite vari tipi di autenticazione. Per scrivere gli esempi abbiamo utilizzato il linguaggio di programmazione Java (J2SE 1.5, J2EE 1.4); come contenitore OC4J (distribuito da Oracle, versione 10g 10.1.3) e Tomcat 5.5 con Axis 1.2 (distribuito dalla fondazione Apache); come ambiente di sviluppo Oracle JDeveloper 10.1.3.

Come primo esempio mostriamo una semplice classe Java:

package articolo;

public class Salve
{
public String saluto(String p)
{
String risultato;
risultato = "Ciao "+p;
return risultato;
}
}

Questa classe contiene un solo metodo che prende in ingresso una stringa e la restituisce concatenata con “Ciao”.

Siamo pronti per creare il nostro primo WebService!

Per prima cosa vediamo come creare il Web Service tramite l’utilizzo dei tool automatizzati di JDeveloper.

Dopo aver selezionato la classe appena creata, clicchiamo con il tasto destro selezionando “Create J2EE Web Service”, e poi J2EE (JAX-RPC) Web service. JDeveloper creerà una serie di file, tra i quali: “web.xml” (il web deployment descriptor) e “Web Services.deploy” (un file per la gestione della fase di deployment). Adesso ci serve una connessione verso il container OC4J, che provvederemo a creare clicclando con il tasto destro sul file .deploy e scegliendo “crea una nuova connessione”. 

Ora possiamo effettuare il deployment tramite tasto destro sopra WebServices. Il nostro metodo è ora presente sull’application server, come possiamo vedere invocando OC4J da browser con l’indirizzo: http://localhost:1810

  

Adesso possiamo richiamare il metodo direttamente da qui oppure creando una classe Stub in java.

Per invocarlo da OC4j dobbiamo effettuare i seguenti passi:

Da OC4J si accede al web service e si clicca su Test Web Module:

Compare una schermata in cui sono elencati i metodi disponibili, in questo caso l’unico metodo saluto. Cliccandoci sopra, compare a video:

Scriviamo “a tutti!” al posto di “simpleType value” e clicchiamo “Invoke”. Il risultato è il seguente:

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns0="http://articolo/Salve/types">

<env:Body>
<ns0:salutoResponseElement>
<ns0:result>Ciao a tutti!</ns0:result>
</ns0:salutoResponseElement>
</env:Body>
</env:Envelope>

Come possiamo osservare, il metodo ha funzionato correttamente.

E’ possibile invocare il metodo anche da JDeveloper, nel seguente modo:

andiamo su MyWebService1 e con il tasto destro su Generate WebServicesStub. Si apre il Wizard di creazione della classe stub. Facciamogli generare il metodo main, lasciando inalterato l’URL. Successivamente vediamo i metodi a disposizione (che saranno disponibili nel webservice), nel nostro caso uno solo. Abbiamo creato la classe MyWebService1Stub.java. Scorriamola e troveremo la dicitura //Add your code here. Da qui scriviamo:

System.out.println(stub.prova("a tutti!"));

Modifichiamo nell’endpoint della classe Stub la porta, scrivendoci 8988. Adesso avviamo l’Embedded OC4J Server cliccando con il tasto destro e poi Run. Avviamo la classe Stub ed il metodo è invocato!

 

Adesso vediamo come farlo con Tomcat ed Axis, usando l’utility WSDLJava per creare il file WSDL: 

1) Andiamo nella directory che contiene il nostro package.

2) “Svuotiamo” il nostro metodo, facendogli ritornare null;

package articolo;

public class Salve
{
public String saluto(String p)
{ return null;
}
} 

3) Compiliamo la classe Salve con il comando: javac articolo\Salve.java

4) Creiamo il file descrittore WSDL:

java org.apache.axis.wsdl.Java2WSDL -o Salve.wsdl -l"http://localhost:8080/axis/services/Salve" -n "urn:Salve" -p"articolo" "urn: Salve " articolo.Salve

Abbiamo generato il file Salve.wsdl.

4) Creiamo i file per il WebService scrivendo:

java org.apache.axis.wsdl.WSDL2Java -o . -s -S true -Nurn:Salve articolo Salve.wsdl

Abbiamo generato diversi file, vediamoli in dettaglio.

Per il WebService: Salve.java, SalveSoapBindingImpl.java, SalveSoapBindingSkeleton.java

Per fare il deployment/undeployment del webservice: deploy.wsdd, undeploy.wsdd

Per il client: SalveService.java, SalveServiceLocator.java

5) E’ giunto il momento di riscrivere nella classe SalveSoapBindingImpl.java il codice che abbiamo eliminato in precedenza

6) Fatto ciò, compiliamo tutte le classi con javac *.java

7) Ultimo passo da fare è creare una cartella “articolo” sotto Tomcat\webapps\axis\WEB-INF\classes e copiarci i file Salve.class, Salve.SoapBindingImpl.class, SalveSoapBinsingSkeleton.class

Scriviamo ora: java org.apache.axis.client.AdminClient articolo\deploy.wsdd

Il Web services è pronto per essere invocato! Testiamolo subito scrivendo nel browser:

http://localhost:8080/axis/servlet/AxisServlet

 

E’ visualizzato il descrittore wsdl. Adesso possiamo invocarlo creando un’apposita classe con Jdeveloper:

package mypackage1;
import org.apache.axis.client.Call;
import org.apache.axis.client.Service;
import javax.xml.namespace.QName;

public class Classeprova
{
public Classeprova()
{
}
public static void main(String [] args) throws Exception {
String endpoint = http://localhost:8080/axis/services/Salve;
String method = "prova" ;
Service service = new Service(); //creo un nuovo servizio
Call call = (Call)service.createCall();
call.setTargetEndpointAddress(new java.net.URL(endpoint));
call.setOperationName(method); // Definisco il metodo da invocare
String ret = (String)call.invoke( new Object [] {"Buongiorno"});
System.out.println("Risultato: " +ret);

}
}

Il risultato è la stringa “Ciao Buongiorno”:

 

Facciamo ora vedere come è possibile invocare un Web Services tramite l’utilizzo di un altro linguaggio di programmazione rispetto a quello con cui lo abbiamo scritto: vediamo come invocare il metodo Salve, tramite uno script in Phyton.

Per prima cosa dobbiamo installare, oltre al Phyton le librerie pyXML, SOAPpy e fpconst. Digitiamo i seguenti comandi dalla shell di Python:

import xml
import fpconst
from SOAPpy import WSDL
server = WSDL.Proxy(“http://localhost:8080/axis/services/ Salve?wsdl”)

La variabile server rappresenta una connessione verso il metodo Ciao. A questo punto, digitando:

print server.methods

apparirà la scritta: [u'Salve], che vuol dire che la nostra variabile è riuscita a leggere il file Salve.wsdl e ad estrapolare il metodo Salve. Naturalmente il Web Services deve essere attivo su Tomcat.

Per provare il metodo: ris= server.prova("Gabriele")

Il risultato dovrebbe essere: “Ciao Gabriele”

 

Ora vediamo come proteggere un Web Services da accessi non autorizzati. Mostreremo come farlo utilizzando prima la Basic Authentication (che prevede l’utilizzo di username e password) poi l’autenticazione tramite lo scambio di certificati (ed il criptaggio dei dati).

Analizziamo la Basic Auhentication ovviamente sia con OC4J sia con Tomcat ed Axis.

Quando abbiamo creato il Web Services con JDeveloper, è stato creato automaticamente il file web.xml. In questo file dovremo aggiungere le specifiche per i ruoli, il tipo di autenticazione e le pagine da proteggere. Le righe da aggiungere sono le seguenti:

<security-constraint>
<web-resource-collection>
<web-resource-name>tutto</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>prova</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
<security-role>
<description>prova</description>
<role-name>prova</role-name>
</security-role>

Il gruppo si chiama “prova”, le pagine da proteggere sono, per semplicità, tutte quelle nella directory e il tipo di autenticazione è BASIC. L’utente per il test è “prova” (la cui password è “1234”).

Dobbiamo adesso modificare il file principals.xml presente nella directory oc4j\j2ee\home\application-deployments\Articolo-Project-WS nel seguente modo: all’interno dei tag <groups> scriviamo:

<group name="prova">
<description>prova</description>
<permission name="rmi:login" />
</group>

Mentre all’interno dei tag <users>:

<user username="prova" password="1234" >
<description>test</description>
<group-membership group="prova" />
</user>

Abbiamo quindi preparato sia il Web Services che il suo contenitore per l’utilizzo dell’autenticazione di tipo BASIC.

E’ necessario ovviamente effettuare un nuovo deployment per il Web Services. Ora dobbiamo costruire una classe che richiami il metodo saluto che abbiamo esposto. Creiamo quindi con il JDeveloper una nuova classe Stub/Skeleton, facendogli generare il metodo main e l’http BASIC authentication code dove come file wsdl gli diamo inizialmente quello del Web Services locale.

Dobbiamo modificare il codice dello Skeleton, modificando le seguenti righe:

props.put(OracleSOAPHTTPConnection.AUTH_TYPE, "basic");
props.put(OracleSOAPHTTPConnection.USERNAME,"prova"); props.put(OracleSOAPHTTPConnection.PASSWORD, "1234");
props.put(OracleSOAPHTTPConnection.REALM, "WebServices");

In pratica, quando lo Skeleton interroga il Web Services, richiamando il metodo Ciao, deve autenticarsi inviando username e password.

Aggiungiamo poi, dove è scritto commentato “Add your code here” il seguente frammento di codice:

String s = stub.prova("Gabriele");
System.out.println(s);
System.out.println(stub.getEndpoint());

Se tutto è andato bene, dovremmo avere in output la stringa “Ciao Gabriele” e l’endpoint successivamente. La classe stub ha fornito l’username e la password al server in modo del tutto trasparente per l’utente. Il server, una volta che il client si è autenticato, ha fornito l’accesso al servizio.

 

Analizziamo adesso l’autenticazione basic con Tomcat ed Axis.

La prima cosa da configurare è il file tomcat-users.xml, aggiungendo all’interno dei tag <tomcat-users> le righe:

<role rolename="prova"/>
<user username="prova" password="1234" roles="prova"/>

Fatto questo, dobbiamo configurare i tag Security Constraints, Login Config e Security Role nel file web.xml di Axis, presente nella directory “Tomcat 5.5\webapps\axis\WEB-INF”. Le righe da aggiungere sono le seguenti:

<security-constraint>
<web-resource-collection>
<web-resource-name>tutto</web-resource-name>
<url-pattern>/services/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>prova</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
<security-role>
<description>prova</description>
<role-name>prova</role-name>
</security-role>

In questo modo abbiamo creato un controllo per l’accesso alla pagina salve.wsdl. In più, tutte le pagine wsdl contenute in /services sono protette. Chi vorrà accedervi, dovrà fornire username e password definiti nel file tomcat-users.xml.

Se ritorniamo con il browser alla pagina di elenco dei files wsdl, adesso dovremmo inserire username e password per accedere ai sorgenti:

 


Ovviamente andrà modificata anche la classe di prova che richiama il metodo. Per fare ciò, è sufficiente fornire username e password prima di invocare il servizio aggiungendo le seguenti righe di codice:

call.setUsername("prova");
call.setPassword("1234");

 

  

 

 

PROTOCOLLO SSL: breve introduzione

Il protocollo SSL utilizza combinazioni di chiavi pubbliche e simmetriche. Una sessione SSL inizia con uno scambio di messaggi effettuati nella fase detta “Handshake”. Vediamola in dettaglio.

Il server ha un certificato che descrive le informazioni riguardanti la società/ente/persona. I campi più rilevanti sono le informazioni di cui sopra e la chiave pubblica. Il tutto è regolato dal Certificato X.509. Tale certificato può essere garantito da una Certification Authority, la quale assicura l’esatta corrispondenza tra il certificato e colui che lo emette. Anche il client può avere un certificato, ma questo serve solo se esso deve ricevere dati sensibili da parte del server. Generalmente è il contrario.

Se la connessione è iniziata dal server, esso invierà al client un messaggio “server hello”. Se è il client ad iniziare la connessione, si avrà in invio un messaggio “hello”. Analizziamo più in dettaglio tale messaggio.

E’ definito dai campi:

1. protocol version: definisce la versione SSl usata;
2. random byte: byte casuali generati dal client;
3. Session identifier: per verificare se si tratta di una nuova sessione o di una aperta in precedenza;
4. Lista delle CipherSuite: è una lista in cui il Client notifica al Server gli algoritmi di crittografia supportati, ordinati in modo decrescente;
5. Lista degli algoritmi di compressione supportati dal Client.

Il Server risponde con un messaggio “server hello” definito nel modo seguente:

1. Protocol version: rappresenta la versione SSl scelta dal Server;
2. Random byte: byte generati in modo casuale;
3. Session identifier: identifica la sessione. Se non è una sessione già aperta, se ne crea una nuova; questo nel caso in cui nel tag “session identifier” del messaggio “hello” sino presenti tutti zeri; Altrimenti viene riesumata la sessione indicata dal client, se presente nella cache del server;
4. ChiperSuite: famiglia di algoritmi di crittografia scelta dal server;
5. Compression method: metodo di compressione scelto da server.

Dopo questo scambio di messaggi, avviene l’autenticazione tramite lo scambio di un certificato. Supponiamo che debba essere il server ad identificarsi. Questo vuol dire che i dati confidenziali transiteranno dal client al server e NON viceversa, in quanto il Client non è identificato. Tale situazione potrebbe essere, per esempio, una fase di acquisto in rete, in cui il client invia i suoi dati personali al Server, quindi è necessario che il Server sia ben identificato. Il Server dunque invia il certificato al Client, insieme alle preferenze riguardo l’algoritmo di crittografia da usare. A questo punto il client verifica che il certificato ricevuto sia valido analizzando vari aspetti. Per prima cosa la data di validità del certificato. In seguito, si verifica che la CA che garantisce il certificato (ammesso che ce ne sia una), sia una CA affidabile. Se lo è, il client recupera la chiave pubblica dalla sua lista di CA sicure per verificare la firma digitale arrivatagli con il certificato del server. Se l’informazione in tale certificato è cambiata da quando è stata firmata da una CA, o se la chiave pubblica nella lista CA non corrisponde alla chiave privata usata dalla CA per firmate il certificato del server, il client non potrà autenticare il server. Infine, il client verifica che il nome del dominio nel certificato server corrisponda allo stesso dominio del server. Questa fase conferma che il server è localizzato nello stesso indirizzo di rete che è specificato nel nome di dominio del suo certificato. Tale controllo previene attacchi del tipo “Man in the Middle”, in quanto se il domain name non corrisponde, molto probabilmente perché il certificato è stato inviato non dal server atteso, ma da una terza persona che si è intromessa. La connessione sarà rifiutata se i due nomi non corrispondono. Se invece tutto è andato a buon fine, il client avrà verificato che il server è affidabile.

A questo punto il client genera una “pre master key” e la cripta con la chiave pubblica del server.

Opzionalmente, in questa fase, può essere richiesta l’autenticazione del client, che è molto simile a quella vista prima, nel seguente modo: esso deve cifrare alcuni valori casuali condivisi con la sua chiave privata, creando in pratica una firma. In più, il server verifica che il client, anche se autenticato, sia autorizzato ad accedere alle risorse richieste. La chiave pubblica nel certificato del client può facilmente convalidare tale firma se il certificato è autentico, in caso contrario la sessione sarà terminata. Il server riceve il messaggio criptato e, verificata l’attendibiltà del client, lo decripta tramite la sua chiave privata. Genera poi una master secret (cosa che fa anche il client, seguendo gli stessi passi) e da questa, insieme, generano la chiave di sessione, una chiave simmetrica che sarà usata per criptare e decriptare i dati che attraversano il tunnel SSL appena creato; inoltre serve per verificare che i dati non vengano alterati nel lasso di tempo che intercorre tra l’invio e la ricezione. A questo punto il client ed il server si inviano un messaggio di notifica di HandShake concluso, e lo scambio di dati può iniziare.

 

Vediamo come implementare il protocollo SSL con la server authentication su Axis.

Sono due le cose da fare: crearsi un certificato e configurare Tomcat in modo che accetti connessioni SSL. Vediamo la prima.

Posizioniamoci nella directory home di Java. Adesso creeremo un keystore per il server e lo esporteremo in un certificato chiamato server.cer. Il keystore altro non è che un repository di certificati usato per identificare il client o il server, in questo caso il server.

Usiamo, per fare ciò, l’utility keytool di Java. Da console scriviamo:

keytool -genkey -alias server-alias -keyalg RSA -keypass changeit -storepass changeit -keystore keystoreserver.jks

ed immettiamo le informazione riguardanti il server.

Successivamente:

keytool -export -alias server-alias -storepass changeit -file server.cer -keystore keystoreserver.jks

Il nostro certificato è pronto e possiamo visionarlo:

Da notare che, giustamente, non è considerato attendibile in quanto non è stato autenticato da una Certification Authority.

Scorrendo il certificato possiamo visionare anche la chiave pubblica:

Il passo successivo prevede di predisporre Tomcat ad accettare connessione SSL. Apriamo il file di configurazione di Tomcat server.xml e togliamo il simbolo di commento dalle righe relative alla connessione SSL :

<Connector
port="8443"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="JAVA_HOME\keystoreserver.jks"
keystorePass="changeit" />

 

Adesso, scrivendo https://localhost:8443 , verrà visualizzato il certificato:

 

 

Se lo accettiamo, saremo in un tunnel SSL:

 

 

Analizziamo adesso la mutua autenticazione SSL. Per mutua autenticazione siintende che l’autenticazione deve essere effettuata sia dal lato client che dal lato server.

La cosa da fare adesso è creare, oltre al certificato del server e del client, un repository di certificati contenenti le chiavi pubbliche che chiameremo cacerts.jks. Questo file serve per verificare l’autenticazione di entrambi, nel modo visto in precedenza. Nel nostro caso, siccome il client ed il server sono la stessa macchina, il repository è uno solo. In genere però, ognuno ha il suo. Analizziamo i passi da fare.

Dal Lato Server:

1) Creiamo un keystore server:>

keytool -genkey -alias server-alias -keyalg RSA -keypass changeit -storepass changeit -keystore keystoreserver.jks

2) Rendiamolo self-signed:

keytool -selfcert -alias server-alias -keystore keystoreserver -keypass changeit -storepass changeit

Ovviamente, in una situazione reale, questo passo dovrebbe essere fatto da una CA. In questo caso ci sostituiamo alla CA per continuare l’esercitazione.

3) Creiamo il file server.cer:

keytool -export -alias server-alias -storepass changeit -file server.cer -keystore keystoreserver.jks

4) Importiamo il tutto nel repository cacerts.jks:

keytool -import -v -trustcacerts -alias server-alias -file server.cer -keystore cacerts.jks -keypass changeit -storepass changeit

Dal Lato Client:

I passi sono analoghi:

1) keytool -genkey -alias client-alias -keyalg RSA -keypass changeit -storepass changeit -keystore keystoreclient.jks

2) keytool -selfcert -alias client-alias -keystore keystoreclient.jks -keypass changeit -storepass changeit

3)keytool -export -alias client-alias -storepass changeit -file client.cer -keystore keystoreclient.jks

4)keytool -import -v -trustcacerts -alias client-alias -file client.cer -keystore cacerts.jks -keypass changeit -storepass changeit

In questo modo, in tutti e due i keystore, vi sono i certificati proprietari, con le rispettive chiavi private e nel cacerts.jks i certificati dell’altro, con le chiavi pubbliche, in modo da fare i confronti per provvedere all’autenticazione.

Nella classe del client, dobbiamo modificare leggermente il codice per permetterle di inviare il certificato del client e di caricare successivamente il repository. Vanno aggiunte le seguenti righe:

System.setProperty("javax.net.ssl.keyStore","D:\\Programmi\\Java\\jdk1.5.0_01\\jre\\bin\\keystoreclient.jks");

System.setProperty("javax.net.ssl.keyStorePassword","changeit");

System.setProperty("javax.net.ssl.trustStore","D:\\Programmi\\Java\\domains\\domain1\\config\\cacerts.jks");

System.setProperty("javax.net.ssl.trustStorePassword","changeit");

Adesso dobbiamo impostare Tomcat per fare i confronti tra certificati. Le impostazioni da fare, per quanto riguarda il file server.xml sono le stesse viste prima per la Server Authentication, con l’unica eccezione di impostare a “true” la variabile “clientauth”.

Tomcat è predisposto per inviare il certificato del server. Non sa però dove cercare il repository, quindi va impostato. Dobbiamo aprire il file tomcat-users.xml ed aggiungere un username che ha ESATTAMENTE GLI STESSI PARAMETRI DI INGRESSO DEL CERTIFICATO DEL CLIENT. Sarebbero le informazioni che si sono inserite nel client.cer quando ci sono state richieste (nome, località, ecc…). Il server deve sapere questi dati perché è proprio tramite questi che analizza l’attendibilità del client.

 

Nel nostro caso, abbiamo inserito il seguente user:

<user username="CN=Client, OU=Client di Prova, O=Prova, L=Grosseto, ST=Gr, C=IT" password="changeit" roles="prova"/>

Ciò, non basta. Dobbiamo impostare Tomcat affinché trovi il repository. Clicchiamo con il tasto destro sull’icona di Tomcat e selezioniamo “Configura”. Andiamo poi su “Java” e poi “Java opsions”.

Aggiungiamo le seguenti impostazioni:

-Djavax.net.ssl.trustStore=JAVA_HOME\bin\cacerts.jks
-Djavax.net.ssl.trustStorePassword=changeit

In pratica, quando Tomcat lancia la JVM, carica anche il cacerts.jks, insieme al certificato del server.

 

 

Come potete osservare, dopo un lasso di tempo in cui si verifica l’autenticazione di entrambi, è possibile invocare il metodo e ricevere il risultato.

 

Vediamo un’esempio di sicurezza sotto OC4j. Useremo, per questo esempio JDeveloper 10.1.3.

Una volta creato il Web Services, dalla classe che espone il metodo, importiamo il file oraks.jks nel nostro progetto ed inseriamolo in una cartella che chiameremo META-INF, sotto la directory SRC. Tale file è un repository di certificati già presente in OC4J, utile per fare il nostro test.

 

Adesso editiamo il file jazn-data.xml presente in OC4J_HOME\j2ee\home\config ed inseriamo lo stesso user visto in precedenza.

Successivamente clicchiamo con il tasto destro sul file creato dal Web Service e selezioniamo “Secure Web Service”. Selezioniamo la caselle “Expect X.509 Certificate to Autenticate”. Seguiamo le indicazioni a video, inserendo le giuste password dove richiesto e selezionando nell’apposita schermata “Use public key to encrypt” immettendo “oracle”.

Nella schermata di selezione del keystore, abilitiamo anche “Specify segnature alias” inserendo “orasign”e “Specify Encryption alias” inserendo “oraenc”.

Effettuiamo il Deployment del nostro Web Services in un modo diverso da quello visto prima: Creiamo un nuovo EAR File da General\Deployment profiles.

In “Application Assembly” passamogli il nostro file.deploy. In Ear Options, creiamo un nuovo gruppo chiamandolo “keys”, passandogli il file oraks.jks. Abbiamo così creato il nostro file.deploy. Con il tasto destro su di esso, facciamo il deployment nel contenitore locale OC4J.

Quello che ci serve adesso è la classe client che invoca il metodo appena esposto. Creiamo un nuovo Web Service Proxy e mettiamolo in sicurezza con “Secure Proxy” tramite tasto destro. Inseriamo le stesse impostazioni messe per il server.

Adesso, invocando il metodo ed usando TCP Packet monitor, è possibile vedere che il server ed il client si sono inviati i dati criptati.