Questo articolo fornisce ulteriori informazioni sull'utilizzo di identità esterne con Identity-Aware Proxy (IAP) anziché 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 a un utente può essere consentito l'accesso. 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à Google e IAM. Sfruttando Identity Platform, invece, 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
Questo è utile se la tua applicazione utilizza già un sistema di autenticazione esterno e la migrazione degli utenti agli Account Google non è pratica.
Multitenancy
L'architettura multi-tenancy di Identity Platform è stata originariamente progettata per scenari B2B, in cui un'azienda vende un servizio ad altre. In questi casi, è comune per gli sviluppatori voler separare la popolazione di utenti in pool isolati. Questi silo sono chiamati tenant.
Considera il seguente diagramma di relazione di fantasia:
In questo esempio, Acme è una casa automobilistica (l'agente) che utilizza Identity Platform per fornire un servizio alle concessionarie (i tenant). Queste concessionarie a loro volta forniscono servizi ai loro clienti, dipendenti e appaltatori. Anche se il servizio è di proprietà del produttore, ogni concessionaria può utilizzare il proprio gruppo di provider di identità per l'autenticazione. L'ambito delle sessioni utente e dei dati è per tenant. Pertanto, se un utente ha relazioni con più concessionarie, ognuna viene gestita in modo indipendente.
A seconda del tuo caso d'uso, puoi strutturare la gerarchia dei tenant in vari modi.
Nessun tenant
Hai bisogno dell'architettura multi-tenancy solo se devi isolare le risorse. Non tutte le applicazioni hanno questo requisito. Ad esempio, se disponi di una sola app App Engine e vuoi bloccare l'accesso a tutti gli utenti all'esterno della rete, non è necessaria l'architettura multi-tenancy. Per impostazione predefinita, Identity Platform archivia e autentica gli utenti in base al singolo progetto, quindi in questo caso non è necessaria alcuna ulteriore configurazione.
Un altro esempio è la conglomerato con diverse società controllate. Anche se ogni società controllata 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, vacanze e libro paga. In questo caso, è sufficiente l'autenticazione a livello di progetto.
Un tenant per risorsa
Per impostazione predefinita, i token Identity Platform non-tenant sono validi a livello di progetto. In teoria, questo 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 evitare la perdita di token, isola ogni IAP assegnando a ciascuno il proprio tenant. I token creati 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, 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, potresti chiedere all'utente di inserire prima il suo indirizzo email, quindi di individuare in modo programmatico un tenant che corrisponde al dominio dell'email. In alternativa, potresti visualizzare una UI 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 trasporta le rivendicazioni del token ID di Identity Platform e l'applicazione può filtrare l'accesso in base a queste attestazioni.
Un esempio di scenario multi-tenancy è un'azienda che offre vantaggi per i dipendenti con molti clienti che condividono un unico portale web. Quando un utente visita il portale, seleziona prima l'azienda (tenant), quindi esegue l'autenticazione con il provider utilizzato dal datore di lavoro con le credenziali aziendali.