Corso di Laurea in Informatica Reti e Sicurezza Informatica Esercitazione 6 Autenticazione in Tomcat per lo sviluppo di Web Service. In questo documento si presentano i meccanismi fondamentali che consentono l accesso ai web service secondo due livelli di sicurezza. Il primo riguarda il meccanismo di base utilizzato da Tomcat per l identificazione degli utenti, il secondo riguarda la comunicazione attraverso Https. Per realizzare il primo meccanismo di autenticazione bisogna 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 X\webapps\axis\WEB-INF. Le righe da aggiungere sono le seguenti: <security-constraint> <web-resource-collection> <web-resource-name>all</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 alle pagine wsdl contenute in /services. 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 Client che richiama il servizio. 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 è espresso nello standard di certificati X.509. Il 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 di 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 utilizzata 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 siano presenti delle cifre tutte pari a zero; 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 se i due nomi non corrispondono.sarà rifiutata Se invece tutto è andato a buon fine, il Client avrà verificato che il Server è affidabile. A questo punto 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) che avviene nel seguente modo: esso deve cifrare alcuni valori casuali condivisi con la sua chiave privata, creando in pratica una firma. Inoltre, 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 la stessa chiave 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 Server authentication su Axis. Sono due le cose da fare: (i) crearsi un certificato e (ii) configurare Tomcat in modo che accetti connessioni SSL. Vediamo la prima. Posizioniamoci nella directory home di Java. Adesso creeremo un keystore per il Server dal quale esporteremo il nuovo certificato creato, chiamandolo 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 visionarne anche la chiave pubblica: Il passo successivo prevede di predisporre Tomcat ad accettare connessioni 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.