Soap01

Web service di autenticazione su LDAP

Warning

Warning

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)