Dans Google Cloud Search, le contrôle des accès est basé sur le 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, autre que l'adresse e-mail de l'utilisateur, pour identifier chaque compte. Cet ID est appelé ID externe.
Créés à l'aide de la console d'administration, les sources d'identité permettent de combler cet écart entre les systèmes d'identité en:
- Définissez un champ d'utilisateur personnalisé pour stocker les ID externes. Ce champ permet de résoudre les 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.
- Le dépôt définit des groupes pour le contrôle des accès 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 différer la recherche de l'utilisateur lors de la création de LCA et de l'indexation des éléments.
Exemple de déploiement
La figure 1 illustre un exemple de déploiement dans lequel une entreprise utilise à la fois des dépôts sur site et dans le cloud. Chaque dépôt utilise un type différent d'ID externe 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 grâce à son attribut sAMAccountName
. Étant donné que le dépôt 2 utilise un attribut sAMAccountName
comme 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. La propriété est nommée selon 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 conserver 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 pouvant servir à 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:
utilisateur | 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) lors de la création de 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 peuvent lire le 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 l'élément id1_identity
d'Ann (SAMAccountName), l'ID se présentera comme suit:
identitysources/id1_identity/users/example/ann
Cet ID entier est appelé ID intermédiaire de l'utilisateur, car il fournit un lien 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 pour un dépôt, consultez la section 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 à des fins de sécurité ou qui se trouvent localement dans un dépôt.
Utilisez l'API Cloud Identity Groups pour créer un groupe et en gérer les adhésions. Pour associer le groupe à une source d'identité, utilisez le nom de la ressource de 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. Créez ensuite 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 vous assurer que l'annuaire cloud connaît à la fois l'ID Google et les ID externes d'un utilisateur:
- Mettez à jour manuellement chaque profil utilisateur via la console d'administration. Cette procédure n'est recommandée que pour les tests et le prototypage avec quelques profils utilisateur.
- Mappez 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. Pour 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 entre Microsoft Active Directory et Cloud Directory, ainsi que les attributs utilisateur pouvant 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é soit prise en compte. Par exemple,
- Si vous essayez de supprimer le 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é présent dans une LCA d'élément, puis que vous créez un groupe avec le même
groupKey
, le nouveau groupe ne fournit pas l'accès à l'élément tant que celui-ci n'est pas réindexé.