Token: se lo conosci non lo eviti

Parliamo delle connessioni internet e delle applicazioni web: si ricorda che, dalla versione 10.1, ArcGIS Server sarà un erogatore di servizi GIS (solo a 64bit) esclusivamente su protocollo http e le connessioni locali non saranno più possibili.
ArcGIS Server ti consente di abilitare la sicurezza per le tue applicazione web e i tuoi servizi web. Naturalmente, oltre a queste, possiamo applicare la sicurezza al nostro sistema ArcGIS Server con utenti utilizzati da ArcGIS Server per accedere ai dati, sicurezza con codice eseguito direttamente sul server e sicurezza mediante dispositivi hardware.
Per gestire la sicurezza per i servizi web e le applicazioni web i passi da seguire sono:

• definire la gestione degli utenti e dei ruoli
• scegliere un metodo di autenticazione
• implementare Secure Sockets Layer (SSL)
• impostare i permessi per i servizi e le applicazioni

La componente fondamentale di qualsiasi meccanismo di controllo degli accessi è la capacità di autenticare gli utenti. Tutti i meccanismi di autenticazione richiedono che le informazioni degli utenti e dei ruoli ai quali fanno riferimento risiedano centralmente da qualche parte del sistema. Le applicazioni ASP.NET consentono che queste informazioni siano memorizzzate e gestite o dal sistema operativo o da un provider membership ASP.NET. ArcGIS Server utilizza queste due opzioni fornite da ASP.NET.

La decisione di optare per una piuttosto che per l'altra dipende da contesto di utilizzo. Se, ad esempio, sviluppiamo applicazioni su una intranet, sicuramente vorremo utilizzare già gli utenti/ruoli definiti nel sistema operativo per garantire l'accesso alle applicazioni. Se stiamo sviluppando applicazioni su internet, invece,  non vogliamo che gli utenti web siano utenti nella nostra active directory; in questo caso memorizziamo questi utenti nel provider membership ASP.NET.

ArcGIS Server consente di configurare facilmente il Membership provider di ASP.NET per SQL Server di Microsoft utilizzando ArcGIS Server Manager. Inoltre, essendo molto flessibile, il provider può essere personalizzato per poterlo utilizzare anche con altre fonti dati come altri database, file xml, ldap ecc. Qui potete vedere come implementare un provider personalizzato.

Quindi riepilogando abbiamo:

• utenti e ruoli definiti a livello di sistema operativo
• membership provider di ASP.NET
        - Microsoft SQL Server (configurabile utilizzando ArcGIS Server Manager)
        - Personalizzato (configurato dall'amministratore/sviluppatore e poi integrato in ArcGIS Server Manager) 

L'autenticazione è il processo tramite il quale il sistema verifica l'identità dell'utente che intende accedere al sistema mediante user e password. Il metodo di autenticazione determina come il server valida l'identità dell'utente.

Per informazioni memorizzate a livello di sistema operativo l'autenticazione avviene con metodo IIS mentre, utilizzando il Membership Provider ASP.NET, l'autenticazione avviene con metodo ASP.NET.

I metodi di autenticazione variano anche in termini di livello di sicurezza fornita.
I metodi di autenticazione disponibili con ArcGIS server per Micorosoft .NET framework sono:

Autenticazione IIS:

• Autenticazione integrata Windows (utilizzata generamente su intranet; utilizza solo utenti definiti a livello di sistema operativo e, quando si utilizza IE sulla rete locale, l'identità è passata in modo trasparente senza prompt di login. Stesso discorso per i client ARCGIS. Questo consente di connettersi ed utilizzare i servizi senza un esplicito accesso con login);
• HTTP Basic e Digest (utilizzata su intranet e internet; utilizza solo utenti definiti a livello di sistema operativo, su browser si ha pop-up di login) 

Autenticazione ASP.NET:

• autenticazione basata su Forms (utilizzata per applicazioni web quando le informazioni utente sono memorizzate in un membership provider, su browser avremo una form di login su una pagina web)
• autenticazione basata su token (implementata da ArcGIS Server, utilizzata solo per servizi web e non per le applicazioni, il client ottiene un token dal server passando user e password e poi il token è utilizzato per accedere al servizio, lavora con utenti memorizzati) 

Importante: per poter supportare più metodi di autenticazione occorre creare istanze multiple di ArcGIS server. Ogni istanza di ArcGIS Server dovrebbe essere legata allo stesso GIS Server ma dovrebbe essere configurata con metodi differenti di autenticazione. Il classico caso è l'utilizzo degli utenti windows su una rete locale e quello degli utenti SQL Server per utenti esterni su internet. In questo caso occorre avere due istanze di ArcGIS Server. Per maggiori dettagli su come implementare più metodi di autenticazione vedete Multiple ArcGIS Server Web instances for security.

In base alle esigenze di memorizzazione delle informazioni dell'utente e del metodo di autenticazione, potresti avere la necessità di acquistare un certificato SSL per il tuo web server. SSL abilita l'utilizzo dell'HTTPS che cripta la comunicazione tra i client e il tuo web server. L'HTTPS è il risultato dell'applicazione di un protocollo di crittografia (SSL o TLS) al protocollo di trasferimento HTTP. Chiaramente, quando gli utenti si autenticano con i metodi di autenticazione HTTP basic, basato su token o basato su forms, SSL può aumentare la sicurezza delle credenziali perchè il passaggio delle informazioni avviene in modo criptato, aumentando il livello di sicurezza di attacchi del tipo man in the middle. Proprio MITM è utilizzato ad esempio da fiddler per decifrare il traffico HTTPS: in sostanza fiddler fa da proxy tra il browser ed il server web. Fiddler comunica con il server web mediante il certificato valido mentre con il browser comunica emettendo un suo certificato per poter decifrare il traffico. Ovviamente il browser ti avverte che il certificato di fiddler non è valido ma accettandolo possiamo eseguire la nostra analisi di traffico su https. Per non ricevere più warning possiamo installare il certificato di fiddler nel browser (raccomandato solo su macchine di test). Per maggiori dettagli sui certificati digitali seguite il link.

Per gli utenti che accedono ai servizi o alle applicazioni, devi aggiungere permessi nei servizi o nelle applicazioni per un ruolo nel quale l'utente è membro. I permessi di ArcGIS Server sono basati su ruoli. Pertanto, per aggiungere permessi per un servizio, per una cartella servizio o per l'applicazione nel manager occorre usare i ruoli piuttosto che i permessi dei singoli utenti.

Quando si applica la sicurezza ad un servizio, essa è applicata a tutte le forme di quel servizio: SOAP, REST e OGC (come ad esempio il WMS). Consentendo l'accesso ad esempio al ruolo Tecnici ad un servizio da manager, fai sì che gli utenti appartenenti a quel ruolo siano abilitati ad accedere attraverso i metodi SOAP, REST e OGC abilitati per il servizio. Analogamente, la services directory rispetta le impostazioni di sicurezza così, una volta che l'utente si è autenticato, potrà vedere solo i servizi per i quali ha l'accesso.

Vediamo ora più nel dettaglio l'autenticazione con il servizio di token fornito da ArcGIS Server. Come abbiamo visto, con l'autenticazione basata su token si utilizza l'autenticazione ASP.NET (SQL Server o un altro provider personalizzato per la memorizzazione di utenti e ruoli).
Un  token si attua come una chiave di accesso ai servizi protetti ed è esclusivamente fornito agli utenti autenticati. Il token è una stringa che cripta delle informazioni che contengono nome dell'utente, periodo di scadenza ed altre informazioni. Il token è fornito all'utente autenticato attraverso i servizi web disponibili in -Istanza ArcGI Server-/Tokens.

Il token fornisce un certo livello di sicurezza per i tuoi servizi gis ma non è certamente più sicuro di altri metodi come un'autenticazione integrata windows. La protezione del tuo sistema con i token dipende dal controllo di accesso ai token. Questo in pratica si traduce nel fatto di far circolare le informazioni su un canale protetto, come precedentemente accennato, utilizzando l'HTTPS. Inoltre è possibile richiedere che tutte le richieste, oltre a quella richiesta per il token, circolino su canale protetto. In questo caso, tramite Manager o ArcCatalog, è possibile impostare Require Encryped Web Access nelle proprietà del folder dei servizi indicati.

Il servizio di token è un servizio web che è installato con la componente ARCGIS Web application durante l'installazione di ArcGIS server. Nella versione 10, il servizio di token è automaticamente abilitato quando necessario. E' abilitato se gli utenti sono memorizzati in un Membership provider. Non è abilitato o utilizzato quando specifichi utenti windows per l'autenticazione dei servizi GIS a meno che utilizzi Membership Provider per i ruoli e abiliti i token per l'autenticazione utente.

Quando il servizio di token è abilitato, puoi impostare un valore massimo consentito di time-out per i token, ovverosia il periodo di tempo oltre il quale il token non è più valido.
E' possibile anche impostare la chiave (Shared key) per criptare il token. Questa chiave è utilizzata per decriptare il token che arriva dal client e verifica l'identita del client. Questa chiave serve per verificare che il server abbia creato il token. Il token è criptato con una chiave utilizzando il metodo di criptazione AES. I 16 caratteri impostati (gli altri non vengono utilizzati) rappresentano i 128 bit utilizzati per la criptazione.

Quando i token sono richiesti per i servizi GIS, i client seguono il seguente approccio:

• Il client fa una richiesta al servizio GIS
• il server GIS risponde che un token è richiesto e fornisce l'url del servizio di token
• il client richiede il token dal servizio di token fornendo user e password
• il servizio di token valida la user e password con il Membership provider impostato e, se valido, restituisce un token al client
• il client fa le richieste al servizio GIS ed include il token con la richiesta
• il server GIS valida il token ed invia la risposta per il servizio richiesto dal client

Per consentire l'utilizzo dei servizi GIS senza fornire un token o una login occorre assegnare al servizio il ruolo di Everyone.

Quando il servizio token è abilitato e richiesto per accedere ai servizi, il client deve essere in grado di ottenere ed usare il token come visto nei passi descritti precedentemente. I client ESRI ottengono ed utilizzano il token automaticamente.

Per ArcGIS Desktop, ArcGIS Explorer e le applicazioni Web ADF, l'utente inserisce la user e la password nella finestra di dialogo della connessione per accedere al servizio. L'applicazione automaticamente si prende cura di comunicare con il servizio di token ed acquisire un valido token.

Le applicazioni basate su SOAP necessitano di acquisire ed utilizzare esplicitamente i token, verificandone la validità di volta in volta.

Le applicazioni basate su REST (javascript, Silverlight/WPF e Flex, SharePoint), poichè sono applicazioni che vengono eseguite lato client, possono essere analizzate da chiuque e pertanto non è opportuno memorizzare la user e la password per accedere al servizio nell'applicazione. Pertanto un token può essere ottenuto dal servizio di token. Il token poi è incluso nella richiesta al servizio.

Occorre ricordare che non vanno confuse le credenziali di accesso all'applicazione con quelle di accesso al token. L'applicazione utilizza il token poichè sono state memorizzate in essa la user e la password di un ruolo autorizzato ad utilizzare il/i servizio/i. L'applicazione inoltre può essere protetta mediante login basata  su utenti che possono anche non avere diretto accesso ai servizi. Quando si utilizza l'autenticazione IIS (utenti memorizzati in Windows) le credenziali di accesso sono passata automaticamente dall'applicazione ai servizi GIS.

Nelle impostazioni di protezione nel Manager, possiamo impostare il time-out dei token. Come abbiamo accennato, il time-out del token è il periodo di tempo che il token rimane valido. Una volta che non è più valido, se viene utilizzato ugualmente, verrà visualizzato un errore.
Possiamo avere due tipi di scadenza di valida per il token:
Token a breve durata: forniscono una maggiore protezione poichè limitano l'utilizzo non autorizzato. Se ad esempio un hacker tiene monitorato la comunicazione tra l'utente ed il server, potrebbe visualizzare il token ed utilizzarlo però, se il tempo di validità è basso, l'utilizzo sarà limitato. Lo svantaggio dei token a breve durata è che lo sviluppatore dovrà richiedere un nuovo token prima che il token perda validità.
Token a lunga durata: questo time-out normalmente è utilizzato dalle applicazioni basate su REST. La validità del token è più duratura rispetto ai token di breve durata. Per ottenere un token di lunga durata, il client deve includere nella richiesta al servizio di token un client ID e un tempo di validità. Il client ID può essere o l'IP del client o il Referrer URL Web (cioè l'url dell'applicazione web che si sta utilizzando). Se non si specifica il periodo di validità, il token verrà considerato di breve durata.

Come si accennava precedentemente, un modo per minimizzare l'uso non autorizzato dei token è richiedere l'utilizzo dell'HTTPS (SSL) per tutte le comunicazioni con i servizi GIS.

Si pensi ad esempio ad un servizio GIS abilitato all'editing (Feature Service): se non fosse protetto, potrebbe essere utilizzato da chiunque per modificare i dati.

Per richiedere il token al server, occorre fare una richiesta URL.

La richiesta per farsi restituire il token dal server è la seguente:

https://myserver.example.com/arcgis/tokens?request=gettoken&username=myuser&password=secret1&clientid=ref.myserver.example.com&expiration=1440&f=json&callback=myfunction

request: il valore di questo parametro è gettoken (obbligatorio)
username: la username di un utente abilitato all'accesso di uno o più servizi (obbligatorio)
password: la password dell'utente (obbligatorio)
clientid: è un parametro opzionale. Si utilizza un "." per dividere il tipo dal valore passato

• ip: indirizzo ip del client. Esempio clientid=ip.10.14.100.38
• ref: la base dell'url dell'applicazione. Esempio clientid=ref.http://myserver/myApp
• requestip: il token è generato per l'IP da dove la richiesta ha avuto origine. Esempio clientid=requestip

expiration: facoltativo. Specifica la durata di validita del token. Se non specificato, il token verrà considerato con impostazione di breve durata.
f: restituisce il risultato in formato json. Facoltativo ed aggiunto a partire dalla 10sp1
callback: facoltativo. Specifica la funzione di callback da utilizzare per farsi restituire il risultato. Se specificata, il formato di restituizione è sempre in json.

Dalla 10 sp1 è possibile utilizzare anche la seguente richiesta:

https://myserver.example.com/arcgis/tokens/generateToken?username=myuser&password=mypass&client=referer|ip|requestip&referer=referer&ip=ipaddress&expiration=expiration&f=json&callback=myfunction


Il servizio di token di default è impostato su connessione che utilizza https. Sebbene non consigliato è possibile, in fase di test, disabilitare l'https. Questo normalmente accade quando si è in fase di test con web server basato su file (Cassini in Visual Studio) che non supportano l'uso di https/ssl.

Per disabilitare l'https occorre aprire il web.config dell'applicazione di Tokens (-Web server root-\ArcGIS\Tokens\web.config) con notepad e andare nella sezione di appSettings

<appSettings>
<add key="RequireSSL" value="True" />
<add key="TokenServiceURL" value="https://myserver/..." />
<appSettings>

Impostare il parametro RequireSSL a false e cambia da https a http l'url in TokenServiceURL.
Per rendere il servizio di token accessibile su internet, occorre modificare i tre web.config in rest, services e token della tua istanza arcgis server. Occorre aprirli con notepad e cambiare l'url nel parametro TokenServiceURL al nome del dominio in sostituzione di quello della macchina.

Negli help dei web client ESRI potete vedere nel dettaglio come utilizzare i token:
javascript
silverlight
flex

Se le applicazioni sono protette con autenticazione basata su token, è possibile utilizzare una pagina di proxy che gestisce la comunicazione tra i servizi ArcGIS Server e la nostra applicazione. Questo permette di non trasmettere il token dal client. La pagina di proxy (codice server-side) riceve la richiesta dal client e la gira ai servizi gis utilizzando il token memorizzato in essa.
Qui potete scaricare e configurare la pagina proxy:
ASP.NET
Java/JSP
PHP

In questo link potete scaricare una versione modificata del proxy page ESRI per poter far chiamate dalla pagina di proxy e richiedere il token senza memorizzarlo nel file di configurazione.
proxyConTokenDinamico

In pratica, ho aggiunto la richiesta di token come visto precedentemente

https://myserver.example.com/arcgis/tokens?request=gettoken&username=myuser&password=secret1&clientid=ref.myserver.example.com&expiration=1440&f=json&callback=myfunction

public string GetToken(string uri)
        {
            foreach (ServerUrl su in serverUrls)
            {
                if (su.MatchAll && uri.StartsWith(su.Url, StringComparison.InvariantCultureIgnoreCase) && su.DynamicToken)
                {
                    // Code to dynamically get the token
                    string tokenService = string.Format("https://{0}/arcgis/tokens?request=getToken&username={1}&password={2}&expiration=30", su.Host, su.UserName, su.Password);
                    string token;
 
 
                    // This script is added to force the application to certify the SSL script (if for example you have a self certificate on server)
                    System.Net.ServicePointManager.ServerCertificateValidationCallback += delegate(object sender, System.Security.Cryptography.X509Certificates.X509Certificate certificate, System.Security.Cryptography.X509Certificates.X509Chain chain, System.Net.Security.SslPolicyErrors sslPolicyErrors)
                    {
                        return true;
                    };
 
 
 
                    System.Net.WebRequest tokenRequest = System.Net.WebRequest.Create(tokenService);
                    System.Net.WebResponse tokenResponse = tokenRequest.GetResponse();
                    System.IO.Stream responseStream = tokenResponse.GetResponseStream();
                    System.IO.StreamReader readStream = new System.IO.StreamReader(responseStream);
                    token = readStream.ReadToEnd();
 
                    return token;
                }
                else if (su.MatchAll && uri.StartsWith(su.Url, StringComparison.InvariantCultureIgnoreCase))
                {
                    return su.Token;
                }
                else
                {
                    if (String.Compare(uri, su.Url, StringComparison.InvariantCultureIgnoreCase) == 0)
                        return su.Token;
                }
            }
 
            if (mustMatch)
                throw new InvalidOperationException();
 
            return string.Empty;
        }

Per fare i propri controlli sul certificato ssl, è possibile utilizzare ServerCertificateValidationCallback, ad esempio per forzare la validità, come nel caso qui sopra, se ci troviamo con un certificato non scaduto ma non rilasciato da un ente riconosciuto (caso di autocertificati)

// This script is added to force the application to certify the SSL script (if for example you have a self certificate on server)
System.Net.ServicePointManager.ServerCertificateValidationCallback += delegate(object sender, System.Security.Cryptography.X509Certificates.X509Certificate certificate, System.Security.Cryptography.X509Certificates.X509Chain chain, System.Net.Security.SslPolicyErrors sslPolicyErrors)
{
      return true;
};

Via SOAP possiamo utilizzare RequiresTokens del servizio Catalog:

Catalog myCatalog = new Catalog();
 
            myCatalog.Url = "http://localhost/arcgis/services";
            string myToken = null;
            if (myCatalog.RequiresTokens())
            {
 
                string tokenServiceUrl = myCatalog.GetTokenServiceURL();
 
                string url = tokenServiceUrl + "?request=getToken&username=myuser&password=secret";
 
                System.Net.WebRequest request = System.Net.WebRequest.Create(url);
 
                System.Net.WebResponse response = request.GetResponse();
 
                System.IO.Stream responseStream = response.GetResponseStream();
 
                System.IO.StreamReader readStream = new System.IO.StreamReader(responseStream);
 
                myToken = readStream.ReadToEnd();
 
            }
 
            MapService_MapServer mapservice = new MapService_MapServer();
 
            mapservice.Url = string.Format("http://localhost/arcgis/services/MapService/MapServer{0}",string.IsNullOrEmpty(myToken)?string.Empty, "?token=" + myToken);

Se il token è scaduto o invalido (codice 498) o richiesto (codice 499) nella gestiore errori si richiede un nuovo token:

try {
 
    mapimg = mapservice.ExportMapImage(mapdesc, imgdesc);
 
}
 
catch (System.Net.WebException webExc) {
 
    System.Net.HttpWebResponse webResp = webExc.Response as System.Net.HttpWebResponse;
 
    if (webResp != null) {
 
        int statusCode = (int)webResp.StatusCode;
 
        if (statusCode == 498 || statusCode == 499) {
 
            // call a method (not shown here) that obtains a new token
 
            string newToken = getToken();
 
        
 
            mapservice.Url = "http://MyWebServer/arcgis/services/MapService/MapServer?token=" + newToken;
 
            mapimg = mapservice.ExportMapImage(mapdesc, imgdesc);
 
        }
 
    }
 
}