VMware console di Cloud Services utilizza OAuth 2.0 in modo da poter concedere alle applicazioni un accesso delegato sicuro alle risorse protette all'interno dell'Organizzazione. VMware Cloud Services supporta l'accesso alle applicazioni Web in cui gli utenti dell'app autorizzano l'accesso e le interazioni da server a server in cui i token di accesso vengono emessi direttamente nell'app.
Che cos'è OAuth 2.0
OAuth 2.0 è un protocollo di autorizzazione che consente di concedere alle app un accesso sicuro alle risorse. Il client è autorizzato tramite un token di accesso. Il token di accesso ha un ambito che definisce a quali risorse può accedere il token. Per informazioni su OAuth 2.0, vedere la specifica OAuth all'indirizzo https://tools.ietf.org/html/rfc6749#page-8 oppure guardare questo post del blog intitolato OAuth 2.0 Simplified all'indirizzo https://aaronparecki.com/oauth-2-simplified/.
Come funziona OAuth 2.0 con VMware Cloud Services
VMware Cloud services copre diversi casi d'uso per l'autorizzazione delle app sfruttando diversi tipi di concessione, come client credentials, authorization code e public client con authorization code. In base ai propri obiettivi, scegliere di creare uno dei tre tipi di app OAuth che corrispondono ad ciascun tipo di concessione, rispettivamente dal Server all'app del server, all'app Web e all'app nativa/mobile.
Si supponga di essere Proprietario dell'Organizzazione con accesso a VMware Cloud on AWS. È stata sviluppata un'app che aiuta a scambiare azioni. L'app viene chiamata Trading 1.0. Si desidera eseguire l'app nelle macchine virtuali gestite da un vCenter Server, ma prima di tutto è necessario autorizzare l'app con le API di VMware Cloud on AWS.
- Viene creata un'app OAuth 2.0 nella console di Cloud Services. Questa azione può essere un modo per registrare l'app Trading 1.0. Per avviare la creazione dell'app, fare clic su Crea App nel menu Organizzazione > App OAuth e seguire una serie di passaggi. Al termine del processo, vengono emesse le credenziali del client sotto forma di ID dell'app e segreto dell'app utilizzati per identificare il client con le API. Incollare queste credenziali nello script.
- L'app è stata creata nell'Organizzazione, ma non le è ancora stato concesso l'accesso. È possibile concedere l'accesso aggiungendola all'Organizzazione. In questo modo l'app può accedere ai servizi e alle risorse dell'Organizzazione definite durante la creazione dell'app. Questo passaggio è necessario solo per le app del tipo da server a server. Non è applicabile alle app Web e native/mobili.
- Quando si esegue l'app client Trading 1.0, viene richiesto un token di accesso dal server di autorizzazione. Se autorizzato, il server di autorizzazione invia un token di accesso alle API di e al client viene concesso l'accesso.
Chi può creare e gestire le app OAuth
In qualità di utente Proprietario dell'Organizzazione o di Membro di un'Organizzazione con il ruolo di Sviluppatore, si ha la possibilità di creare e gestire le app OAuth.
È inoltre possibile gestire le app OAuth create o aggiunte da altri proprietari dell'Organizzazione all'interno dell'Organizzazione.
È possibile rigenerare un segreto dell'app?
Sì, in qualità di Proprietario dell'Organizzazione, si ha la possibilità rigenerare il segreto app di un'app OAuth nell'Organizzazione. Questo è utile se il Proprietario dell'Organizzazione che ha creato l'app OAuth non è più nell'azienda ma si desidera continuare a eseguire l'app.
È possibile utilizzare un'autenticazione token API anziché un'app OAuth?
Sì, se un'API impone che un utente sia l'entità autenticata nel processo di autorizzazione, è necessario utilizzare un token API. Per visualizzare quando utilizzare le app OAuth rispetto ai token API, vedere Qual è la differenza tra le app OAuth e i token API?.
