Dans Google Cloud Search, le contrôle des accès dépend du compte Google de l'utilisateur. Lors de l'indexation du contenu, toutes les LCA associées aux éléments doivent correspondre à des ID d'utilisateur ou de groupe Google valides (adresses e-mail).
Dans de nombreux cas, un dépôt ne connaît pas directement les comptes Google. À la place, les utilisateurs peuvent être représentés par des comptes locaux ou utiliser une connexion fédérée avec un fournisseur d'identité et un ID, autres que leur adresse e-mail, pour identifier chaque compte. Cet ID est appelé ID externe.
Créées à l'aide de la console d'administration, les sources d'identité permettent de combler l'écart entre les systèmes d'identité en:
- définir un champ d'utilisateur personnalisé pour stocker les ID externes ; Ce champ permet de résoudre des ID externes vers un compte Google.
- Définissez un espace de noms pour les groupes de sécurité gérés par un dépôt ou un fournisseur d'identité.
Utilisez des sources d'identité dans les cas suivants:
- Le dépôt ne connaît pas l'adresse e-mail principale de l'utilisateur dans l'annuaire Google Workspace ou Google Cloud.
- Pour le contrôle des accès, le dépôt définit des groupes qui ne correspondent pas aux groupes basés sur les adresses e-mail dans Google Workspace.
Les sources d'identité améliorent l'efficacité de l'indexation en dissociant l'indexation du mappage d'identité. Ce découplage vous permet de reporter la recherche de l'utilisateur lors de la création de LCA et de l'indexation d'éléments.
Exemple de déploiement
La figure 1 présente un exemple de déploiement dans lequel une entreprise utilise des dépôts sur site et dans le cloud. Chaque dépôt utilise un type d'ID externe différent pour faire référence aux utilisateurs.
Le dépôt 1 identifie l'utilisateur à l'aide de l'adresse e-mail déclarée à l'aide du protocole SAML. Étant donné que le dépôt 1 connaît l'adresse e-mail principale de l'utilisateur dans l'annuaire Google Workspace ou l'annuaire cloud, une source d'identité n'est pas nécessaire.
Le dépôt 2 s'intègre directement à un répertoire sur site et identifie l'utilisateur par son attribut sAMAccountName
. Étant donné que le dépôt 2 utilise un attribut sAMAccountName
en tant qu'ID externe, une source d'identité est nécessaire.
Créer une source d'identité
Si vous avez besoin d'une source d'identité, consultez Associer des identités d'utilisateur dans Cloud Search.
Vous devez créer une source d'identité avant de créer un connecteur de contenu, car vous aurez besoin de l'ID de la source d'identité pour créer des LCA et indexer les données. Comme indiqué précédemment, la création d'une source d'identité entraîne également la création d'une propriété utilisateur personnalisée dans l'annuaire cloud. Utilisez cette propriété pour enregistrer l'ID externe de chaque utilisateur de votre dépôt. Le nom de la propriété suit la convention IDENTITY_SOURCE_ID_identity
.
Le tableau suivant présente deux sources d'identité : l'une pour conserver les noms de compte SAM (sAMAccountName) en tant qu'ID externes et l'autre pour les ID utilisateur (uid) en tant qu'ID externes.
Source d'identité | propriété utilisateur | ID externe |
---|---|---|
id1 | id1_identity | sAMAccountName |
id2 | id2_identity | uid |
Créez une source d'identité pour chaque ID externe possible permettant de faire référence à un utilisateur de votre entreprise.
Le tableau suivant montre comment un utilisateur disposant d'un compte Google et de deux ID externes (id1_identity et id2_identity) et leurs valeurs apparaissent dans l'annuaire cloud:
user | adresse e-mail | id1_identity | id2_identity |
---|---|---|---|
Anne | ann@example.com | exemple\anne | 1001 |
Vous pouvez référencer le même utilisateur à l'aide des trois ID différents (adresse e-mail Google, sAMAccountName et uid) lorsque vous créez des LCA pour l'indexation.
Écrire des LCA utilisateur
Utilisez les méthodes getUserPrincpal() ou getGroupPrincipal() pour créer des comptes principaux à l'aide d'un ID externe fourni.
L'exemple suivant montre comment récupérer les autorisations de fichiers. Ces autorisations incluent le nom de chaque utilisateur ayant accès au fichier.
L'extrait de code suivant montre comment créer des comptes principaux qui sont propriétaires à l'aide de l'ID externe (externalUserName
) stocké dans les attributs.
Enfin, l'extrait de code suivant montre comment créer des comptes principaux qui sont les lecteurs du fichier.
Une fois que vous disposez de la liste des lecteurs et des propriétaires, vous pouvez créer la LCA:
L'API REST sous-jacente utilise le modèle identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID
pour l'ID lors de la création des comptes principaux. Si vous créez une LCA avec le paramètre id1_identity
d'Anne (SAMAccountName), l'ID serait le suivant:
identitysources/id1_identity/users/example/ann
Cet ID complet est appelé ID intermédiaire de l'utilisateur, car il fournit un pont entre l'ID externe et les ID Google stockés dans l'annuaire cloud.
Pour en savoir plus sur la modélisation des LCA utilisées dans un dépôt, consultez la page LCA.
Mapper les groupes
Les sources d'identité servent également d'espace de noms pour les groupes utilisés dans les LCA. Vous pouvez utiliser cette fonctionnalité d'espace de noms pour créer et mapper des groupes utilisés uniquement pour des raisons de sécurité ou des groupes locaux dans un dépôt.
Utilisez l'API Cloud Identity Groups pour créer un groupe et en gérer les membres. Pour associer le groupe à une source d'identité, utilisez le nom de la ressource de la source d'identité comme espace de noms du groupe.
L'extrait de code suivant montre comment créer un groupe à l'aide de l'API Cloud Identity Groups:
Créer une LCA de groupe
Pour créer une LCA de groupe, utilisez la méthode getGroupPrincipal() afin de créer un compte principal de groupe à l'aide d'un ID externe fourni. Ensuite, créez la LCA à l'aide de la classe Acl.Builder comme suit:
Connecteurs d'identité
Bien que vous puissiez utiliser des ID externes autres que Google pour créer des LCA et indexer des éléments, les utilisateurs ne peuvent pas voir les éléments d'une recherche tant que leurs ID externes ne sont pas associés à un ID Google dans l'annuaire cloud. Il existe trois façons de s'assurer que Cloud Directory connaît à la fois l'ID Google et les ID externes d'un utilisateur:
- Mettre à jour manuellement chaque profil utilisateur via la console d'administration Cette procédure n'est recommandée que pour les tests et le prototypage utilisant un petit nombre de profils utilisateur.
- Mapper des ID externes avec des ID Google à l'aide de l'API Directory Cette procédure est recommandée si vous ne pouvez pas utiliser le SDK Identity Connector.
- Créez un connecteur d'identité à l'aide du SDK Identity Connector. Ce SDK simplifie l'utilisation de l'API Directory pour mapper les ID.
Les connecteurs d'identité sont des programmes permettant de mapper des ID externes entre les identités d'entreprise (utilisateurs et groupes) et les identités Google internes utilisées par Google Cloud Search. Si vous devez créer une source d'identité, vous devez créer un connecteur d'identité.
Google Cloud Directory Sync (GCDS) est un exemple de connecteur d'identité. Ce connecteur d'identité mappe les informations sur les utilisateurs et les groupes de Microsoft Active Directory vers l'annuaire cloud, ainsi que les attributs utilisateur susceptibles de représenter leur identité dans d'autres systèmes.
Synchroniser les identités à l'aide de l'API REST
Utilisez la méthode update
pour synchroniser les identités à l'aide de l'API REST.
Remappage des identités
Après avoir remappé l'identité d'un élément à une autre identité, vous devez réindexer les éléments pour que la nouvelle identité s'applique. Par exemple :
- Si vous essayez de supprimer un mappage d'un utilisateur ou de le remapper à un autre utilisateur, le mappage d'origine est conservé jusqu'à ce que vous le réindexiez.
- Si vous supprimez un groupe mappé qui figure dans une LCA d'élément, puis que vous créez un groupe avec la même
groupKey
, ce nouveau groupe ne fournit pas l'accès à l'élément tant que celui-ci n'est pas réindexé.