Soap01
Web service di autenticazione su LDAP
Esiste una soluzione migliore: Shibboleth.
Shibboleth è più sicuro, più semplice e più flessibile ed inoltre offre il Single Sign On. Non usate questo servizio se non avete ottime ragioni per farlo.
Il server http://soap01.unimore.it è un intermediario per l'autenticazione su LDAP. Gli sviluppatori di applicazioni web che non vogliono occuparsi di chiamate dirette al server LDAP possono delegarle a soap01.unimore.it.
Il meccanismo di interrogazione si differenzia a seconda se i dati di autenticazione dell'utente sono mandati per POST sul server web che contiene l'applicazione o direttamente a soap01.unimore.it.
La prima via, per i server web con https, è più semplice ed elegante: il server web si connette a soap01.unimore.it con il protocollo SOAP e recupera i dati di autenticazione.
Interrogazione diretta del web service SOAP con username e password
Il web service usa SOAP e XML/RPC. Per usare il protocollo SOAP, il file wsdl si trova a:
https://soap01.unimore.it/auth/backend/service.wsdl
Il metodo di autenticazione si chiama "Auth" (case sensitive!) e si aspetta una username e una password.
Risponde con un array di oggetti "VectorInfo" che sono composti da un attributo stringa "key" che contiene il nome del campo LDAP restituito e un attributo array "value" che ne contiene i valori (che possono essere multipli).
Gli errori sono contenuti nel "VectorInfo" "error" che altrimenti non è presente.
Client in ruby
require 'soap/wsdlDriver'
wsdl='https://soap01.unimore.it/auth/backend/service.wsdl'
item_server=SOAP::WSDLDriverFactory.new(wsdl).create_rpc_driver
res = item_server.Auth('username', 'passwd')
res.each do |a|
puts a.key + " = " + a.value.join(", ")
end
Client in php
Bisogna installare il supporto soap:
apt-get install php-soap
<?php
$wsdl="https://soap01.unimore.it/auth/backend/service.wsdl";
$client=new SoapClient($wsdl);
$res=$client->Auth("username", "password");
foreach ($res as $v)
{
echo $v->key." = ".join(", ",$v->value)."\n";
}
?>
(testato solo su php5)
Ridirezione della form
Nel caso il server web non disponga di https o comunque voglia ridirigere il POST della form del client al server soap01, esistono due possibilità di recuperare i dati collegati all'utente che si è autenticato:
- soap01 fa un redirect sul web server e rende un token grazie al quale il web server ritira i dati utente tramite protocollo SOAP;
- soap01 fa un redirect al web server e passa in GET i dati utenti cifrati e firmati.
La form del client deve essere ridiretta nel primo caso a: https://soap01.unimore.it/auth/frontend/auth, i campi devono chiamarsi "username" e "password" e deve essere presente un campo hidden "jump_to" con la pagina su cui fare il redirect del browser del client. "jump_to" deve essere il nome dns dell'host (non l'IP).
Nel secondo caso la ridirezione avviene a https://soap01.unimore.it/auth/frontend/auth_crypt oppure https://soap01.unimore.it/auth/frontend/auth_appli, a seconda se si voglia specificare il campo "jump_to" oppure "appli". Il campo "appli" contiene un codice applicazione da cui soap01 ricava la pagina a cui fare la redirezione. Ovviamente ogni nuovo codice "appli" deve essere inserito nell'applicazione (chiedere al redattore di questo articolo).
Restituzione di un token
soap01 restituisce in GET un parametro "unique_id" che permette di recuperare i dati utenti, tramite una chiamata al metodo FindInfoById dello stesso web service citato in precedenza, "backend". Il file wsdl che identifica il servizio SOAP è quindi lo stesso (https://soap01.unimore.it/auth/backend/service.wsdl), il formato dati restituito è identico (un array di VectorInfo).
Restituzione dei dati cifrati
In questo scenario tutti i dati del risultato dell'autenticazione dell'utente sono presentati direttamente come parameri GET in coda all'indirizzo a cui il browser è stato ridiretto, previa semplice codifica Base64. Per evitate manipolazioni, è presente un hash che permette di verificare l'integrità dei dati.
I parametri restituiti sono:
- query_data: l'esito dell'operazione Encode in Base64
- digest: lo hash SHA1 di ( query_data prima del Base64 + codice segreto da richiedermi )
In query_data c'è anche una marcatura temporale, che deve essere controllata, altrimenti l'applicazione è vulnerabile agli attacchi replay.
--Malvezzi 12:45, 7 February 2007 (CET)