In questo articolo vengono fornite informazioni aggiuntive sull'utilizzo di identità esterne con Identity-Aware Proxy (IAP) anziché con gli 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 a un utente deve essere consentito l'accesso. IAP è un componente di base di Chrome Enterprise Premium, una soluzione di sicurezza aziendale che consente ai dipendenti di lavorare da 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 e così via)
- SAML
- OIDC
- Numero di telefono
- Personalizzato
- Anonimo
Questa opzione è 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 diagramma delle relazioni fittizie riportato di seguito:
In questo esempio, Acme è un produttore di auto (l'agente) che utilizza Identity Platform per fornire un servizio ai concessionari (i tenant). Questi concessionari a loro volta forniscono servizi ai propri clienti, dipendenti e appaltatori. Sebbene il produttore sia proprietario del servizio, ogni concessionario potrebbe utilizzare il proprio set di provider di identità per l'autenticazione. Le sessioni e i dati degli utenti sono limitati a livello di tenant, quindi se un utente ha relazioni con più concessionari, ognuna viene gestita in modo indipendente.
A seconda del caso d'uso, puoi strutturare la gerarchia dei tenant in diversi modi.
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 al di fuori della tua rete, non è necessaria la multitenancy. Per impostazione predefinita, Identity Platform archivia e autentica gli utenti a livello di progetto, quindi in questo caso non è necessaria alcuna configurazione aggiuntiva.
Un altro esempio è un conglomerato con diverse filiali. Anche se ogni filiale ha il proprio sistema di autenticazione gestito (utilizzando OIDC o SAML), tutti i dipendenti potrebbero condividere gli stessi vantaggi di alto livello, come assistenza sanitaria, ferie e busta 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, quindi utilizzare il token per accedere a un altro servizio nello stesso progetto. Si tratta di un rischio per la sicurezza.
Per evitare la perdita di token, isola ogni IAP assegnando a ciascuno il proprio tenant. I token generati 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 quale tenant utilizzare. Ad esempio, potresti chiedere all'utente di inserire prima la sua email e poi individuare a livello di programmazione un tenant che corrisponda al dominio dell'email. In alternativa, potresti 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 livelli di accesso diversi. Sebbene non sia possibile utilizzare IAM per gestire il controllo dell'accesso con identità esterne, il token web JSON generato da IAP contiene le attestazioni del token ID di Identity Platform e l'applicazione può filtrare l'accesso in base a queste attestazioni.
Un esempio di scenario di multitenancy è un'azienda di benefit per i dipendenti che ha molti clienti che condividono un unico portale web. Quando un utente visita il portale, seleziona prima la sua azienda (il tenant), quindi si autentica con il provider utilizzato dal suo datore di lavoro con le credenziali aziendali.