Questo articolo fornisce ulteriori informazioni 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 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 da reti non attendibili senza utilizzare una VPN.
Per impostazione predefinita, IAP utilizza identità Google e IAM. Se utilizzi 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
Ciò è utile se la tua applicazione utilizza già un sistema di autenticazione esterno e la migrazione degli utenti agli Account Google non è fattibile.
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 silo sono denominati tenant.
Considera il seguente diagramma delle relazioni fittizie:
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 a clienti, dipendenti e collaboratori. Sebbene il produttore sia il proprietario del servizio, ogni concessionaria potrebbe utilizzare il 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 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
Hai bisogno del multitenancy 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 è necessario il multitenancy. Per impostazione predefinita, Identity Platform memorizza e autentica gli utenti in base al 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 (che utilizza OIDC o SAML), tutti i dipendenti potrebbero condividere gli stessi vantaggi 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 Identity Platform non multitenant 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 creati 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 il suo indirizzo email e poi individuare a livello di programmazione 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 il controllo dell'accesso dell'accesso con identità esterne, il token web JSON generato da IAP contiene le rivendicazioni del token ID Identity Platform e l'applicazione può filtrare l'accesso in base a queste rivendicazioni.
Un esempio di scenario multi-tenant è 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 esegue l'autenticazione con il provider utilizzato dal suo datore di lavoro con le sue credenziali aziendali.