Identità esterne

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questo articolo fornisce ulteriori informazioni sull'utilizzo delle identità esterne con Identity-Aware Proxy (IAP) anziché sugli Account Google.

Panoramica

IAP controlla l'accesso alle app di App Engine e alle VM di Compute Engine in esecuzione su Google Cloud. Sfrutta l'identità dell'utente e il contesto di una richiesta per determinare se l'utente deve essere autorizzato ad accedere. IAP è un componente di base per la realizzazione di BeyondCorp, un modello di sicurezza aziendale che permette ai dipendenti di lavorare da reti non attendibili senza utilizzare una VPN.

Per impostazione predefinita, IAP utilizza identità Google e IAM. Utilizzando Identity Platform, puoi autenticare gli utenti con un'ampia gamma di provider di identità esterni, ad esempio:

  • Email/password
  • OAuth (Google, Facebook, Twitter, GitHub, Microsoft ecc.)
  • SAML
  • OIDC
  • Numero di telefono
  • Personalizzato
  • Anonimo

Ciò è utile se l'applicazione utilizza già un sistema di autenticazione esterno e la migrazione degli utenti agli Account Google non è pratica.

Multitenancy

La multi-tenancy di Identity Platform è stata originariamente progettata per scenari B2B, dove un'azienda vende un servizio ad altre aziende. In questi casi, è comune per gli sviluppatori voler separare le popolazioni di utenti in pool isolati. Questi silos sono definiti tenant.

Esamina il diagramma di relazione fittizio di seguito:

Una gerarchia multi-tenant

In questo esempio, Acme è un produttore di auto (l'agente) che utilizza Identity Platform per fornire un servizio alle concessionarie (i tenant). Questi rivenditori offrono a loro volta servizi per i clienti, i dipendenti e i contrattisti. Sebbene il servizio sia di proprietà del produttore, ogni concessionaria potrebbe utilizzare un proprio set di provider di identità per l'autenticazione. Le sessioni utente e i dati sono limitati in base al tenant, quindi se un utente ha relazioni con più concessionari, ogni gestione viene gestita in modo indipendente.

A seconda del caso d'uso, hai a disposizione diversi modi per strutturare la gerarchia di tenant.

Nessun tenant

Ti serve la multi-tenancy solo se devi isolare le risorse. Non tutte le applicazioni hanno questo requisito. Ad esempio, se hai un'unica app App Engine e vuoi bloccare l'accesso a tutti gli utenti esterni alla tua rete, non è necessaria la modalità multi-tenancy. Per impostazione predefinita, Identity Platform archivia e autentica gli utenti in base al singolo progetto, quindi in questo caso non è richiesta alcuna configurazione aggiuntiva.

Un altro esempio è un conglomerato con diverse consociate. Anche se ogni consociata ha il proprio sistema di autenticazione gestita (con OIDC o SAML), tutti i dipendenti potrebbero condividere gli stessi vantaggi generali, come assistenza sanitaria, vacanze e busta paga. In questo caso, l'autenticazione a livello di progetto è sufficiente.

Un tenant per risorsa

Per impostazione predefinita, i token di Cloud Identity non tenant sono validi a livello di progetto. In teoria, ciò significa che un utente potrebbe autenticarsi con una risorsa IAP, quindi utilizzare il token per accedere a un altro servizio nello stesso progetto. Questo rappresenta un rischio per la sicurezza.

Per prevenire la fuga di token, isola ogni IAP assegnando ogni tenant. I token emessi in un contesto specifico per il tenant sono validi solo per quel tenant specifico. Se l'utente tenta di accedere a un'altra risorsa IAP che utilizza un tenant diverso, verrà chiesto di eseguire nuovamente l'autenticazione.

Più tenant per risorsa

A una singola risorsa IAP possono essere associati più tenant.

Quando un utente accede alla risorsa, hai a disposizione diverse opzioni per determinare il tenant da utilizzare. Ad esempio, potresti chiedere all'utente di inserire prima il suo indirizzo email e poi localizzare in modo programmatico un tenant corrispondente al dominio dell'email. In alternativa, potresti mostrare un'interfaccia utente che elenca tutti i tenant validi e chiedere all'utente di sceglierne uno.

Gli utenti possono appartenere a più tenant con diversi livelli di accesso. Anche se non puoi utilizzare IAM per gestire il controllo dell'accesso con identità esterne, puoi filtrare l'accesso in base al tenant selezionato o alle attestazioni token ID sottostanti dell'utente.

Uno scenario di multi-tenancy di esempio è un'azienda di benefit per i dipendenti con molti clienti che condividono un unico portale web. Quando un utente visita il portale, seleziona prima la sua azienda (il tenant) e poi esegue l'autenticazione con il fornitore utilizzato dal datore di lavoro con le proprie credenziali aziendali.

Passaggi successivi