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 Chrome Enterprise Premium, una soluzione di sicurezza aziendale che consente ai dipendenti di lavorare su reti non attendibili senza utilizzare una VPN.
Per impostazione predefinita, IAP utilizza le identità Google e IAM. Utilizzando invece 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
Questo è utile se la tua applicazione utilizza già un sistema di autenticazione esterno e la migrazione degli utenti agli Account Google non è pratica.
Multitenancy
La multitenancy di Identity Platform è stata originariamente progettata per scenari B2B, in cui un'azienda vende un servizio ad altre aziende. In questi casi, è comune che gli sviluppatori vogliano separare le popolazioni di utenti in pool isolati. Questi silos sono chiamati tenant.
Considera il seguente diagramma delle relazioni fittizio:
In questo esempio, Acme è un produttore di auto (l'agente) che utilizza Identity Platform per fornire un servizio alle concessionarie (i tenant). Queste concessionarie, a loro volta, forniscono servizi ai propri clienti, dipendenti e collaboratori. Sebbene il produttore sia proprietario del servizio, ogni concessionaria potrebbe utilizzare il proprio set di provider di identità per l'autenticazione. Le sessioni e i dati degli utenti hanno un ambito per tenant, quindi se un utente ha relazioni con più concessionarie, ognuna viene gestita 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 una singola app App Engine e vuoi bloccare l'accesso a tutti gli utenti esterni alla tua rete, non è necessario il multi-tenancy. Per impostazione predefinita, Identity Platform archivia e autentica gli utenti in base al progetto, quindi in questo caso non è necessaria 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 benefit di alto livello, come assistenza sanitaria, ferie e buste paga. In questo caso, l'autenticazione a livello di progetto è sufficiente.
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. Questo è un rischio per la sicurezza.
Per evitare la fuga di token, isola ogni IAP assegnando a ciascuno 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 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 diverse opzioni per determinare quale tenant utilizzare. Ad esempio, puoi chiedere all'utente di inserire prima la sua email e poi individuare in modo programmatico un tenant che corrisponda al dominio dell'email. In alternativa, puoi visualizzare 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 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 è una società di benefit per i dipendenti che ha molti clienti che condividono un unico portale web. Quando un utente visita il portale, seleziona prima la propria azienda (il tenant), quindi esegue l'autenticazione con il provider utilizzato dal datore di lavoro con le proprie credenziali aziendali.