Esporta (0) Stampa
Espandi tutto

Selezionare un protocollo di autenticazione

Aggiornamento: febbraio 2014

 

Logo DataMarket

Creare un'applicazione e offrirla sul mercato a una base di consumatori ampia e in costante crescita tramite il Marketplace. Anche se la propria applicazione non utilizza dati del Marketplace, è possibile essere membri della community che si avvale del Marketplace per la vendita delle applicazioni. Provisioning e fatturazione vengono eseguiti automaticamente tramite il Marketplace e lo sviluppatore non dovrà fare altro che coglierne i benefici. Se l'applicazione utilizza dati del Marketplace, l'utente dovrà essere autenticato e autorizzato per poter accedere al set di dati.

Windows Azure Marketplace (WAM) supporta due protocolli di autenticazione, l'autenticazione di base HTTP e OAuth. Per decidere quale protocollo usare, occorre determinare chi e in che modo userà l'applicazione.

Selezionare un protocollo di autenticazione

Sia l'autenticazione di base HTTP che l'autenticazione OAuth sono in grado di autenticare un utente e, a seconda dei casi, concedere o negare l'accesso a una risorsa protetta.

Rispondendo a queste domande per la propria applicazione, è possibile determinare quale è preferibile usare:

  • L'applicazione sarà venduta tramite il Marketplace?

  • L'utente accederà a uno o più set di dati del Marketplace?

Se si risponde "Sì" a una o entrambe queste domande, il protocollo di autenticazione richiesto è OAuth.

Autenticazione di base HTTP

L'implementazione dell'autenticazione di base HTTP del Marketplace ignora l'ID utente e come password richiede solo una chiave dell'account privata valida. È possibile ignorare l'ID utente oppure, se si preferisce gestire direttamente l'utilizzo e la fatturazione, è possibile usarlo per identificare utenti specifici. Se l'applicazione usa il protocollo di autenticazione di base HTTP per accedere al Marketplace:

  • Tutta la procedura di accesso viene eseguita con un singolo account.

  • Tutti gli utenti condividono e usano una singola password (la chiave dell'account del Marketplace).
    Sia che la chiave dell'account venga inclusa nel codice o immessa dall'utente, sarà meno privata e riservata, introducendo in tal modo potenziali vulnerabilità.

  • Tutti gli accessi vengono fatturati tramite il Marketplace a un singolo account, ovvero al proprietario della chiave dell'account, probabilmente lo sviluppatore.

  • Se si rimuove l'accesso per un utente, tramite la modifica della chiave dell'account, verrà rimosso l'accesso per tutti gli utenti.

  • Solo i set di dati sottoscritti dal proprietario della chiave dell'account sono disponibili per gli utenti.

  • Se si vuole che singoli utenti paghino l'utilizzo dei dati, è necessario gestirne l'uso individuale e provvedere direttamente alla fatturazione.

Vedere Implementare l'autenticazione di base HTTP nell'app del Marketplace.

OAuth

L'implementazione di OAuth del Marketplace utilizza il Windows Live ID e la password dell'utente, oltre alla chiave di registrazione dell'applicazione (client_id) per eseguire l'autenticazione e concedere l'accesso ai set di dati. L'uso di OAuth fornisce alcuni vantaggi aggiuntivi in termini di sicurezza, ad esempio la possibilità di autenticare il client e l'utente e di rilasciare un token di accesso direttamente al client, senza potenzialmente esporlo ad altri, incluso il proprietario della risorsa.

Se l'applicazione usa il protocollo OAuth per accedere al Marketplace:

  • È necessario che l'applicazione sia registrata con il Marketplace.

  • Ogni utente deve avere un Windows Live ID.

  • L'accesso avviene totalmente tramite l'account individuale dell'utente.

  • La fatturazione viene effettuata sull'account dell'utente individuale.

  • La rimozione dell'accesso per un utente non influisce sugli altri utenti.

  • Sono accessibili tutti i set di dati sottoscritti dall'utente (se l'applicazione supporta questo scenario).

  • La fatturazione e l'account dell'utente sono gestiti dal Marketplace.

Vedere Implementare OAuth nell'app del Marketplace.

Considerato quanto illustrato sopra, è ragionevole chiedersi perché allora si dovrebbe usare l'autenticazione di base HTTP. Esistono due motivi: 1) il codice richiesto per implementare l'autenticazione di base HTTP è più semplice e più breve del codice per implementare OAuth e 2) se un unico utente userà l'applicazione, la flessibilità e la complessità di OAuth non sono necessarie.

Vedere anche

Mostra:
© 2015 Microsoft