Identità esterne

Questo articolo fornisce ulteriori informazioni sull'utilizzo di identità esterne con Identity-Aware Proxy (IAP) al posto degli Account Google.

Panoramica

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

Per impostazione predefinita, IAP utilizza le identità Google o IAM. Utilizzando invece Identity Platform, puoi autenticare gli utenti con un'ampia gamma di provider di identità esterni, quali:

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

È utile se la tua applicazione utilizza già un'autenticazione esterna ed eseguire la migrazione degli utenti agli Account Google non è attuabile.

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, è pratica che gli sviluppatori vogliano separare gruppi di utenti in gruppi piscine. Questi silos sono chiamati tenant.

Considera il seguente diagramma relativo alle relazioni fittizie:

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 produttore sia il proprietario del servizio, ogni concessionario possono utilizzare il proprio insieme di provider di identità per l'autenticazione. Sessioni utente e i dati hanno un ambito specifico per ogni tenant, quindi se un utente ha relazioni con da più concessionari, ognuno dei quali è gestito in modo indipendente.

A seconda del caso d'uso, esistono vari modi per strutturare nella 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 è rappresentato da un conglomerato con varie società controllate. Anche se ogni controllata ha il proprio sistema di autenticazione gestito (utilizzando OIDC o SAML), tutti i dipendenti possono condividere gli stessi vantaggi di alto livello, come assistenza sanitaria, vacanze 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 livello. In teoria, ciò significa che un utente può autenticarsi con un risorsa IAP, quindi utilizza il token per accedere a un altro servizio all'interno dello stesso progetto. Si tratta di un rischio per la sicurezza.

Per evitare la perdita di token, isola ogni IAP assegnando a ognuno il proprio tenant. I token inseriti 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 proprio indirizzo email, quindi individuare in modo programmatico un tenant che corrisponda il dominio dell'email. In alternativa, potresti visualizzare una UI che elenca tutte le tenant e chiedi 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à, il token web JSON generato da IAP trasporta il token le rivendicazioni del token ID Identity Platform e l'applicazione può filtrare l'accesso sulla base di tali dichiarazioni.

Un esempio di scenario multi-tenancy è quello di un'azienda di benefit per i dipendenti che ha che condividono un unico portale web. Quando un utente visita la dal portale, seleziona prima la propria azienda (il tenant) e poi presso qualsiasi fornitore utilizzato dal datore di lavoro con le proprie credenziali aziendali.

Passaggi successivi