Applicazioni SaaS B2B per Google Cloud Platform multi-tenant

Questo articolo affronta le sfide di autenticazione e autorizzazione descritte nell’articolo Concetti.

Sia l’autenticazione che l’autorizzazione sono intrinsecamente legate all’identità.

Esistono numerosi meccanismi di identità in Google Cloud Platform, tutti elementi che possono fungere da responsabili della politica di autorizzazione:

  • Le identità cloud rappresentano le identità degli utenti e possono anche essere utilizzate per l’autenticazione.
  • Google Gruppi rappresentano raggruppamenti di identità utente. Esistono diversi tipi di Google Gruppi; ci concentreremo sui gruppi Admin Console.
  • Gli account di servizio vengono utilizzati principalmente per rappresentare le applicazioni, in genere tramite l’autenticazione basata su OAuth.
  • Domini Google; esamineremo questi in modo più approfondito nell’articolo Come: isolamento.
  • Gli URL firmati sono token temporizzati per l’autorizzazione di upload e download di Google Cloud Storage.

Identità cloud

Come descritto in precedenza, le identità cloud sono il meccanismo di autenticazione dell’utente principale. Le identità possono essere federate tramite SAML e OpenID Connect; ciò significa che i tuoi clienti possono o federare i propri utenti direttamente con Google Cloud Platform oppure puoi federare gli utenti dei loro clienti per loro conto se hanno già una relazione di federazione con te, ad esempio tramite ADFS.

Il provider di servizi SAML di Google Cloud supporta un singolo IDP SAML, quindi per supportare più tenant di clienti dovrai adottare uno dei seguenti approcci:

  • Utilizzare un broker SAML come Apigee o Auth0.
  • Allocare un dominio o sottodominio per cliente se si stanno fornendo al cliente funzionalità di gestione per l’utente finale (vedere l’articolo sull’isolamento per ulteriori informazioni al riguardo).

Si noti che la federazione Google Cloud non supporta SAML dinamico (ovvero creazione di identità al momento dell’autenticazione); le identità cloud degli utenti devono essere fornite in anticipo utilizzando uno dei meccanismi supportati:

  • Soluzioni di gestione delle identità come Oracle Identity Manager, PingFederate o Okta (ignora il marchio Google Apps e G Suite legacy; si applicano anche a Cloud Identity).
  • Google Cloud Directory Sync (GCDS).
  • Admin Directory SDK API (ignora il marchio G Suite legacy; questo vale anche per Cloud Identity).
  • Caricamento foglio di calcolo (ignora il marchio G Suite legacy; questo vale anche per Cloud Identity). Questa è una buona corrispondenza per i clienti che provano il tuo servizio.

In alcuni casi potresti voler fornire un portale di provisioning degli utenti self-service agli utenti dei tuoi clienti. Il seguente frammento di codice Python mostra come sfruttare l’API Directory SDK di amministrazione per questo caso d’uso:

  # Elencare gli utenti nel dominio dall'individuazione dell'importazione googleapicic 
da google.oauth2 import service_accountSCOPES = ("https://www.googleapis.com/auth/admin.directory.group","https://www.googleapis.com/auth/admin.directory.user")
SUBJECT = '[SERVICE_USER @ DOMAIN]' target_key_file = '[YOUR_KEY_FILE.JSON]'
credentials = service_account.Credentials.from_service_account_file (target_key_file)
scoped_credentials = credentials.with_scopes (SCOPES)
delegated_credentials = scoped_credentials.with_subject (SUBJECT) admin_client = discovery.build ('admin', 'directory_v1', credentials = delegated_credentials)
req = admin_client.users (). list (domain = '[CUSTOMER_DOMAIN]')
resp = req.execute ()
utenti = resp ['utenti'] stampa utenti

Per un’implementazione più completa, vedi questa applicazione di esempio.

Accesso a Google

Per quei clienti per i quali una soluzione basata su SSO non è appropriata, l’accesso a Google offre un modo semplice per sfruttare l’infrastruttura di autenticazione di Google per le tue applicazioni SaaS. Fornisce i seguenti controlli password:

  • applicazione della lunghezza e della forza
  • applicazione della rotazione
  • prevenzione del riutilizzo

Fornisce inoltre una forte protezione dal phishing con applicazione 2FA e reimpostazione della password basata su API (esempio di frammento Python di seguito)

  # Reimposta password dal rilevamento importazione googleapiclient 
da google.oauth2 import service_accountdomain = '[YOUR_DOMAIN]'
delegated_admin = '[YOUR_SERVICE_ADMIN]' # solo id (cioè senza @dominio)
key_file = '[SERVICE_ACCOUNT_JSON_KEY_FILE]'
user = '' .join (['YOUR_USER', '@', domain])
password = 'NEW_PASSWORD'scope = ("https://www.googleapis.com/auth/admin.directory.user",)
subject = '' .join ([delegated_admin, '@', domain]);
delegated_credentials = service_account.Credentials.from_service_account_file (key_file, scopes = scope, subject = subject) authorized_service = discovery.build ('admin', 'directory_v1', credentials = delegated_credentials)
req = authorized_service.users (). update (userKey = user, body = {"password": password, "changePasswordAtNextLogin": True})
resp = req.execute () stampa resp

Account di servizio

Gli account di servizio vengono utilizzati principalmente per rappresentare le applicazioni; questo fornisce un meccanismo naturale per autorizzare i tuoi clienti tramite OAuth.

Un modello tipico prevede che tu o il tuo cliente emettiate un account di servizio e che l’altra parte lo autorizzi come principale. Questo ha diversi vantaggi:

  • Se il tuo cliente emette l’account del servizio, può essere totalmente responsabile della gestione dell’accesso, in modo che tu come fornitore SaaS non sia necessario fornire ai tuoi clienti funzionalità di gestione o federazione dell’utente finale.
  • Supporta l’autorizzazione per joint venture in cui l’accesso ai dati è a) temporizzato eb) entità commerciale anziché vincolata all’utente.
  • La registrazione e il controllo della piattaforma Google Cloud rispecchieranno l’account del servizio, semplificando la fatturazione e l’addebito.

Questo modello presenta anche alcune limitazioni:

  • Non fornisce un meccanismo per l’autenticazione degli utenti finali
  • Gli account di servizio devono essere concessi e gestiti al livello richiesto di autorizzazione, fatturazione e riaddebito, il che può comportare la proliferazione degli account di servizio e le sfide relative alla gestione del ciclo di vita degli operatori. La proliferazione può essere mitigata tramite il ruolo Creatore token account di servizio, che consente la rappresentazione degli account di servizio per creare token di accesso OAuth2 e firmare BLOB o JWT. È possibile sfruttare questa funzionalità per consentire agli utenti di coniare token come richiesto o di mappare gli account del servizio clienti agli account del servizio dell’applicazione.

Gli account di servizio sono ovviamente anche parte integrante della comunicazione tra i servizi della propria applicazione di micro-servizi SaaS (vedere questo articolo per un’implementazione di esempio di App Engine).


Una delle principali sfide dell’autorizzazione è la mappatura della politica dell’utente dei clienti sulla politica dell’utente delle applicazioni GCP.

Ci sono un paio di approcci qui; quale scegli dipenderà in gran parte dal caso d’uso.

  • Reclami SAML: il cliente è interamente responsabile della gestione di quali utenti sono autorizzati ad accedere a quali servizi e dati; puoi associarli ai gruppi Admin Console (vedi sotto) o agli account dei servizi per sfruttare il supporto nativo di Cloud IAM per questi.
  • Admin Console Gruppi o account di servizio: fornisci una console di gestione attraverso la quale i tuoi clienti definiscono l’autorizzazione dell’utente.

Reclami SAML

Google Cloud Platform IAM non supporta direttamente i reclami SAML, quindi dovrai interpretare i reclami nella tua applicazione o in un broker SAML come Apigee o Auth0.

Apigee supporta l’iniezione di politiche per una serie di politiche di sicurezza predefinite e politiche personalizzate di scripting (ad esempio, gli utenti con l’attributo cliente = MySecureCustomer nelle loro asserzioni SAML possono accedere alle API con? Cliente = argomenti MySecureCustomer)

Questo esempio di IDP / provider di servizi SAML fornisce informazioni di risposta decodificate ed è un’ottima piattaforma di test.

Gruppi Admin Console

I gruppi Admin Console sono gestiti dagli amministratori di dominio Cloud Identity (piuttosto che da utenti finali arbitrari) e possono essere forniti e configurati tramite API (ignorare il marchio G Suite legacy; questo vale anche per Cloud Identity).

Esistono due modi per sfruttare i gruppi per l’autorizzazione

  • Concedi ruoli IAM della piattaforma cloud a Google Gruppi.
  • La tua applicazione può sfruttare l’API dei gruppi Admin SDK (ignora il marchio G Suite legacy; questo vale anche per Cloud Identity) per scoprire quali utenti sono membri di un gruppo, nonché a quali gruppi appartiene un membro e i gruppi principali immediati di un gruppo in una gerarchia di gruppi nidificati (imposta userKey sull’utente o sul gruppo di cui desideri trovare i genitori).

Si noti che l’applicazione ha visibilità solo nei gruppi Admin Console che appartengono al suo dominio, a meno che non sia stata concessa esplicitamente un’ulteriore autorizzazione tramite la delega a livello di dominio (vedere l’articolo sull’isolamento per ulteriori informazioni al riguardo); vale a dire. la tua applicazione generalmente non riesce a trovare i gruppi principali su un altro dominio di cui è membro un utente sul dominio primario.

Rappresentazione dell’utente

È possibile combinare account di servizio con identità cloud per consentire a un account di servizio di agire per conto degli utenti su un dominio, ad es. impersonare l’utente, tramite delega dell’autorità a livello di dominio (ignorare il marchio G Suite legacy; questo vale anche per le API di Cloud Identity). Questo è molto utile per affrontare un paio di casi d’uso:

  • Le risorse (ad es. Oggetti GCS) create dall’applicazione devono essere ACL per l’utente finale del cliente. Puoi gestirlo manualmente tramite le API IAM, ma la rappresentazione dell’utente se ne occupa automagicamente.
  • L’applicazione deve esporre le risorse appropriate agli utenti del cliente in base alla loro identità. La gestione manuale richiederebbe essenzialmente di creare un livello ACL all’interno dell’applicazione; la rappresentazione dell’utente lo fa accadere automagicamente.

Leggi questo articolo per saperne di più su questo approccio e le sue limitazioni, nonché per esempi di codice.


Prova le API in API Explorer.

Distribuire un portale di provisioning utente self-service.

Configurare un IDP / provider di servizi SAML di esempio.

Leggi le seguenti guide per capire come implementare:

  • Isolamento SaaS B2B multi-tenant.
  • Rappresentazione dell’utente.

Mille grazie a Mike McDonald per essere stato una cassa di risonanza e un avvocato per l’autenticazione multi-tenant.