La sicurezza prima di tutto!

A partire da ArcGIS Server 10.4 abbiamo a disposizione un tool da eseguire da riga di comando chiamato serverScan.py. Il tool esegue la scansione del tuo site ArcGIS Server per verificare se è stato configurato seguendo le best practise raccomandate da Esri per quel che riguarda la sicurezza.
Il tool è presente nella cartella

C:\Program Files\ArcGIS\Server\tools\admin

e, una volta eseguito, restituisce un report html.
Come potete notare dall'estensione del file è un tool scritto in Python.
Analogamente è presente un tool chiamato portalScan.py ( ..\Portal\tools\security) che controlla la configurazione del Portal per verificare che siano rispettate le best practise raccomandate da Esri.

Qui potete vedere un esempio di report generato dal tool.

Il tool analizza 12 problematiche legate alla sicurezza dividendole in tre livelli di severità: critico, importante e raccomandato. Qui potete trovare l'elenco.

I parametri da passare al tool sono il nome completo della macchina, la user/password dell'admin del site e la cartella di output dove generare il report.

Con ArcGIS Server federato è possibile anche passare il token (-t in riga di comando) generato dal portal da https://mydomain/portal/sharing/rest/generateToken con Client impostato a Webapp URL al nome del dominio (esempio https://mydomain ) al posto della user/password del PSA

Mentre, se si genera il token dall'administrator directory di ArcGIS Server ( arcgis/admin/generateToken ), occorre impostare per il Client Request IP.

Esempio:

python serverScan.py -n gisserver.domain.com -u admin -p mypassword -o C:\Temp

Vediamo ora nel dettaglio i criteri che vengono verificati:

SS01 Critico

Verifica se la comunicazione con ArcGIS Server è criptata su canale ssl derminando se è abilitato l'https. Se il web adaptor è installato è raccomandato che la comunicazione sia protetta.
In questo caso viene evidenziato che la connessione avviene solo in http con arcgis server.

Inoltre abbiamo la possibilità di specificare i protocolli SSL. I predefiniti ArcGIS Server sono il TLS v1.0, TLS v1.1 e il TLS v1.2. Sono stati tolti SSL 2.0 e SSL 3.0 perché obsoleti e insicuri. Se decidiamo di abilitare solo il TLS v1.2 - attualmente il più sicuro in base ai cifrari utilizzati e comunque quello che supporta le criptazioni autenticate più moderne (ad esempio AEAD) - occorrerà verificare il web server che ospita il web adaptor possa comunicare con il TLS 1.2. Il TLS v1.0 è un protocollo legacy che viene ancora utilizzato ma, se possibile, è meglio evitarlo visto che anche se i moderni browser mitigano le sue debolezze presenta comunque problemi.

Per disabilitare SSL2  e SSL3 in Windows occorre

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0\Client]
“DisabledByDefault”=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0\Server]
“Enabled”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 3.0\Client]
“DisabledByDefault”=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 3.0\Server]
“Enabled”=dword:00000000

Inoltre è raccomandato disabilitare l'algoritmo di cifratura RC4 che è insicuro

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128]
"Enabled"=dword:00000000

Per disabilitare Diffie-Hellman vedi questo articolo.

Inoltre dovrebbe essere evitate le seguenti obsolete primitive crittografiche:

- Anonymous Diffie-Hellman (ADH) non forniscono autenticazione;

- NULL cipher non forniscono crittografia.
- Export cipher sono insicuri quando negoziati in una connessione, ma possono anche essere utilizzati con server che preferiscono cipher forti
- cipher deboli  (tipicamente di 40 e 56 bits) usano crittografia che può essere decifrata.
- 3DES è lento e debole.

Questa potrebbe essere un buon punto di partenza come sequenza di cifratori da utilizzare

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

Purtroppo di cifrari occorre prevederne più di uno per la retrocompatibilità con i client che utilizzano il servizio e pertanto, per garantire la compatibilità, occorre trovare il miglior compromesso di suite di priorità di ordine.

Se volete testare il vostro ssl utilizzate l'indirizzo: ssllabs

Per ricevere un rating A+ su sistemi windows occorre avere solo abilitato il TLS 1.2 e l'HSTS (vedi questo articolo per abilitarlo su IIS)

  

SS02 Critico

Verifica se le query standardizzate sono imposte da ArcGIS Server. Per fornire protezione ad attacchi di SQL injection - essendo tale livello considerato critico - l'opzione è abilitata e ArcGIS Server verifica le query non consentendo di utilizzare specifiche funzioni e sintassi del database sottostante.

Qui puoi vedere come utilizzare le funzioni con query standardizzate.

Se non presente, è abilitato mentre se occorre disabilitarlo bisogna dichiararlo in system->properties

SS03 Critico

Verifica se la generazione del token via GET è supportata. Quando viene generato il token via GET le credenziali sono inviate come parte dell'URL e possono così essere visualizzate attraverso la history del browser o i log della rete. Dovrebbe essere disabilitato a meno che sia richiesto esplicitamente da altre applicazioni. Se non presente, è false altrimenti occorre dichiararlo in security->tokens. L'impostazione predefinita è false.

SS04 Critico
Verifica se la generazione del token via POST con le credenziali nei parametri della query string è supportata. Le problematiche sono le stesse dell'SS3 e pertanto andrebbe disabilitato. Se non presente è false altrimenti occorre dichiararlo in security->tokens. L'impostazione predefinita è false.

SS05 Critico
Visualizza un elenco di feature service dove la proprietà filter web content è disabilitata. Disabilitando questa proprietà, consenti all'utente di inserire nei campi di input qualsiasi cosa, ciò potrebbe esporre il servizio a potenziali attacchi XSS. Questa proprietà è abilitata in modo  predefinito e, a meno di entità o attributi HTML richiesti, non deve essere abilitata. Qui potete vedere la lista delle entità e attributi HTML supportati.

SS06 Critico
Controlla se i permessi non predefiniti sono applicati alla cartella System nel Server Manager.
L'impostazione predefinita consente solo agli amministratori e ai pubblicatori di avere accesso ai servizi contenuti nella cartella System.

SS07 Importante
Controlla se la directory dei servizi REST è accessibile attraverso un web browser. A meno che non venga utilizzata attivamente per cercare e trovare servizi da parte degli utenti, dovrebbe essere disattivata per ridurre la possibilità che i servizi possano essere visualizzati, trovati tramite una ricerca su web o interrogati tramite i moduli HTML. Inoltre fornisce un'ulteriore protezione contro attacchi XSS. In system->handlers->rest->servicesdirectory->edit può essere disabilitata.

SS08 Importante
Controlla se le richieste cross - domain sono limitate a specifici domini. Per ridurre la possibilità che applicazioni sconosciute inviino comandi malevoli ai tuoi servizi web, una best practice è limitare l'utilizzo dei tuoi servizi web alle applicazioni ospitate solo ai domini sicuri. Pertanto in system->handlers->rest->servicesdirectory->edit è possibile impostare nella casella AllowedOrigins al posto dell'asterisco la lista dei domini consentiti separati da una virgola (es: http://host.arcgis.com, https://gisserver.example.com)

SS09 Importante
Visualizza una lista di servizi dove il database può essere accessibile via workspace dinamici.
Abilitare il servizio ai workspace dinamici deve essere adeguatamente salvaguardato per evitare che accessi di terze parti possano creare dei danni alla banca dati connettendosi via rest. Pertanto la funzionalità deve essere abilitata solo se realmente necessaria all'applicazione web. In quest'ultimo caso occorrerà connettersi al database dando solo i privilegi minimi di sola lettura alle tabelle strettamente necessarie.

SS10 Raccomandato
Verifica se uno o più web adaptor sono registrati su HTTPS. Per consentire al Server Manager di reindirizzare in https, tutti i web adaptor dovrebbero essere registrati su HTTPS.

SS11 Raccomandato

Verifica se l'account del PSA è abilitato. E' consigliato disabilitare questo account per assicurarsi che non ci sia altro modo di amministrare ArcGIS Server se non tramite i gruppi o i ruoli specificato nell'identity store.  In security->psa è possibile disabilitare l'account PSA.

SS12 Raccomandato

Visualizza una lista di servizi feature che ha le operazioni di update e delete abilitate e non sono protetti.

Questo consente che i dati possano essere modificati o cancellati senza autenticazione.

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);
 
        }
 
    }
 
}