Il controllo dell'accesso in Google Cloud Search si basa sull'Account Google dell'utente. Durante l'indicizzazione dei contenuti, tutti gli ACL sugli elementi devono risolversi in ID utente o gruppo Google (indirizzi email) validi.
In molti casi un repository non ha conoscenza diretta degli account Google. Gli utenti possono invece essere rappresentati da account locali o utilizzare l'accesso federato con un provider di identità e un ID, diversi dall'indirizzo email dell'utente, per identificare ogni account. Questo ID è chiamato ID esterno.
Create utilizzando la Console di amministrazione, le origini identità aiutano a colmare questo divario tra i sistemi di identità:
- La definizione di un campo utente personalizzato per archiviare gli ID esterni. Il campo viene utilizzato per risolvere gli ID esterni in un Account Google.
- Definisci uno spazio dei nomi per i gruppi di sicurezza gestiti da un repository o un provider di identità.
Utilizza le origini identità quando:
- Il repository non conosce l'indirizzo email principale dell'utente in Google Workspace o Google Cloud Directory.
- Il repository definisce gruppi per il controllo dell'accesso che non corrispondono ai gruppi basati su email in Google Workspace.
Le origini identità migliorano l'efficienza dell'indicizzazione disaccoppiando l'indicizzazione dalla mappatura delle identità. Questo disaccoppiamento consente di posticipare la ricerca dell'utente durante la creazione di ACL e l'indicizzazione degli elementi.
Deployment di esempio
La Figura 1 mostra un esempio di deployment in cui un'azienda utilizza i repository on-premise e cloud. Ogni repository usa un tipo diverso di ID esterno per fare riferimento agli utenti.
Il repository 1 identifica l'utente utilizzando l'indirizzo email dichiarato utilizzando SAML. Poiché il repository 1 conosce l'indirizzo email principale dell'utente in Google Workspace o Cloud Directory, non è necessaria un'origine identità.
Il repository 2 si integra direttamente con una directory on-premise e identifica l'utente in base al suo attributo sAMAccountName
. Poiché il repository 2 utilizza un attributo sAMAccountName
come ID esterno, è necessaria un'origine identità.
Crea un'origine identità
Se ti serve un'origine identità, consulta Mappare le identità degli utenti in Cloud Search.
Devi creare un'origine identità prima di creare un connettore di contenuti perché avrai bisogno dell'ID origine identità per creare ACL e indicizzare i dati. Come accennato in precedenza, la creazione di un'origine identità crea anche una proprietà utente personalizzata in Cloud Directory. Utilizza questa proprietà per registrare l'ID esterno per ogni utente nel repository. Il nome della proprietà utilizza la
convenzione IDENTITY_SOURCE_ID_identity
.
La tabella seguente mostra due origini identità: una per i nomi degli account SAM (sAMAccountName) come ID esterni e l'altra per gli ID utente (uid) come ID esterni.
Origine identità | proprietà utente | ID esterno |
---|---|---|
id1 | id1_identity | sAMAccountName |
id2 | id2_identity | uid |
Crea un'origine identità per ogni possibile ID esterno utilizzato per fare riferimento a un utente nella tua azienda.
La seguente tabella mostra in che modo un utente con un Account Google e due ID esterni (id1_identity e id2_identity) e i relativi valori vengono visualizzati in Cloud Directory:
utente | id1_identity | id2_identity | |
---|---|---|---|
Anna | ann@example.com | esempio\ann | 1001 |
Puoi fare riferimento allo stesso utente utilizzando i tre diversi ID (email di Google, sAMAccountName e uid) durante la creazione degli ACL per l'indicizzazione.
Scrivi gli ACL degli utenti
Utilizza il metodo getUserPrincpal() o il metodo getGroupPrincipal() per creare entità utilizzando un ID esterno fornito.
L'esempio seguente mostra come recuperare le autorizzazioni dei file. Queste autorizzazioni includono il nome di ciascun utente che ha accesso al file.
Il seguente snippet di codice mostra come creare entità proprietarie utilizzando l'ID esterno (externalUserName
) archiviato negli attributi.
Infine, il seguente snippet di codice mostra come creare entità che sono lettori del file.
Una volta creato un elenco di lettori e proprietari, puoi creare l'ACL:
L'API REST sottostante utilizza il pattern
identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID
per l'ID durante la creazione delle entità. Facendo riferimento alle tabelle precedenti,
se crei un ACL con id1_identity
di Ann (SAMAccountName), l'ID
viene risolto in questo modo:
identitysources/id1_identity/users/example/ann
Questo intero ID è chiamato ID intermedio dell'utente perché fornisce un bridge tra l'ID esterno e gli ID Google archiviati con Cloud Directory.
Per ulteriori informazioni sulla modellazione degli ACL utilizzati per un repository, consulta ACL.
Gruppi di mappe
Le origini identità fungono anche da spazio dei nomi per i gruppi utilizzati negli ACL. Puoi utilizzare questa funzionalità dello spazio dei nomi per creare e mappare i gruppi utilizzati solo per scopi di sicurezza o che sono locali di un repository.
Utilizza l'API Cloud Identity Groups per creare un gruppo e gestire le iscrizioni. Per associare il gruppo a un'origine identità, utilizza il nome della risorsa dell'origine identità come spazio dei nomi del gruppo.
Il seguente snippet di codice mostra come creare un gruppo utilizzando l'API Cloud Identity Groups:
Crea un ACL di gruppo
Per creare un ACL di gruppo, usa il metodo getGroupPrincipal() per creare un'entità di gruppo utilizzando un ID esterno fornito. Quindi, crea l'ACL utilizzando la classe Acl.Builder come segue:
Connettori di identità
Sebbene tu possa utilizzare ID esterni non Google per creare ACL e indicizzare elementi, gli utenti non possono visualizzare gli elementi in una ricerca fino a quando i loro ID esterni non si trasformano in un ID Google in Cloud Directory. Esistono tre modi per assicurarsi che Cloud Directory conosca sia l'ID Google sia gli ID esterni di un utente:
- Aggiornare manualmente ogni singolo profilo utente tramite la Console di amministrazione Questa procedura è consigliata solo per i test e la prototipazione utilizzando pochi profili utente.
- Mappa gli ID esterni agli ID Google utilizzando l'API Directory. Questa procedura è consigliata per chi non può utilizzare l'SDK Identity Connector.
- Crea un connettore di identità utilizzando l'SDK Identity Connector. Questo SDK semplifica l'utilizzo dell'API Directory per gli ID mappa.
I connettori di identità sono programmi utilizzati per mappare gli ID esterni dalle identità aziendali (utenti e gruppi) alle identità Google interne utilizzate da Google Cloud Search. Se devi creare un'origine identità, devi creare un connettore di identità.
Google Cloud Directory Sync (GCDS) è un esempio di connettore di identità. Questo connettore di identità mappa le informazioni su utenti e gruppi da Active Directory di Microsoft a Cloud Directory insieme agli attributi utente che potrebbero rappresentare la loro identità in altri sistemi.
Sincronizzare le identità utilizzando l'API REST
Utilizza il metodo update
per sincronizzare le identità mediante l'API REST.
Rimappatura delle identità
Dopo aver eseguito la nuova mappatura dell'identità di un elemento a un'altra identità, devi reindicizzare gli elementi affinché la nuova identità entri in vigore. Ad esempio:
- Se provi a rimuovere una mappatura da un utente o la rimappa a un altro utente, la mappatura originale viene conservata finché non esegui la reindicizzazione.
- Se elimini un gruppo mappato presente in un ACL degli elementi e poi crei un nuovo gruppo con lo stesso
groupKey
, il nuovo gruppo non fornirà l'accesso all'elemento finché l'elemento non verrà reindicizzato.