Identità esterne

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

Panoramica

IAP controlla l'accesso alle tue applicazioni e risorse. Sfrutta l'identità dell'utente e il contesto di una richiesta per determinare se un utente deve essere autorizzato ad accedere. IAP è un componente di base di BeyondCorp, un modello di sicurezza aziendale che consente ai dipendenti di lavorare da reti non attendibili senza utilizzare una VPN.

Per impostazione predefinita, IAP utilizza le identità e IAM di Google. Se utilizzi Identity Platform, puoi autenticare gli utenti con una vasta gamma di provider di identità esterni, ad esempio:

  • Email/password
  • OAuth (Google, Facebook, Twitter, GitHub, Microsoft e così via)
  • SAML
  • OIDC
  • Numero di telefono
  • Personalizzato
  • Anonimo

Questa opzione è utile se la tua applicazione utilizza già un sistema di autenticazione esterno ed è impraticabile eseguire la migrazione degli utenti agli Account Google.

Multitenancy

Il multitenancy di Identity Platform è stato progettato originariamente per scenari B2B, in cui un'azienda vende un servizio ad altre aziende. In questi casi, è normale che gli sviluppatori vogliano separare i gruppi di utenti in pool isolati. Questi silos sono chiamati tenants.

Considera il seguente diagramma di relazioni fittizio:

Una gerarchia multi-tenant

In questo esempio, Acme è un produttore di auto (l'agente) che utilizza Identity Platform per fornire un servizio ai concessionari (i tenant). Queste concessionarie a loro volta forniscono servizi ai propri clienti, dipendenti e contraenti. Sebbene il servizio sia di proprietà del produttore, ogni concessionario potrebbe utilizzare il proprio set di provider di identità per l'autenticazione. Le sessioni e i dati degli utenti sono definiti in base al tenant, pertanto se un utente ha rapporti con più concessionari, ognuno viene gestito in modo indipendente.

A seconda del caso d'uso, esistono diversi modi per strutturare la gerarchia dei tenant.

Nessun tenant

La multitenancy è necessaria 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 multitenancy. Per impostazione predefinita, Identity Platform archivia e autentica gli utenti in base al progetto, pertanto in questo caso non è richiesta alcuna configurazione aggiuntiva.

Un altro esempio è un conglomerato con diverse società controllate. Anche se ogni filiale ha il proprio sistema di autenticazione gestito (che utilizza OIDC o SAML), tutti i dipendenti potrebbero condividere gli stessi vantaggi di alto livello, come assistenza sanitaria, ferie e stipendi. In questo caso, è sufficiente l'autenticazione a livello di progetto.

Un tenant per risorsa

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

Per evitare la fuga di token, isola ogni IAP assegnandogli il proprio tenant. I token coniati in un contesto specifico del tenant sono validi solo per quel tenant specifico. Se l'utente tenta di accedere a un'altra risorsa IAP che utilizza un tenant diverso, gli verrà chiesto di autenticarsi di nuovo.

Più tenant per risorsa

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

Quando un utente accede alla risorsa, hai diverse opzioni per determinare il tenant da utilizzare. Ad esempio, potresti chiedere all'utente di inserire prima il suo indirizzo email e poi individuare tramite programmazione un tenant corrispondente al dominio dell'email. In alternativa, puoi 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. Sebbene non sia possibile utilizzare IAM per gestire il controllo dell'accesso con identità esterne, il token web JSON generato da IAP contiene le rivendicazioni del token ID di Identity Platform e l'applicazione può filtrare l'accesso in base a queste rivendicazioni.

Un esempio di scenario multi-tenancy è un'azienda che offre vantaggi ai dipendenti e ha molti clienti che condividono un unico portale web. Quando un utente visita il portale, seleziona prima la propria azienda (l'account tenant) e poi si autentica con il fornitore utilizzato dal suo datore di lavoro con le credenziali aziendali.

Passaggi successivi