Synchroniser différents systèmes d'identité

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:

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.

Exemple de déploiement
Figure 1. Exemple de déploiement d'entreprise avec différents types d'identités

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 email 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.

FilePermissionSample.java
/**
 * Sample for mapping permissions from a source repository to Cloud Search
 * ACLs. In this example, POSIX file permissions are used a the source
 * permissions.
 *
 * @return Acl
 * @throws IOException if unable to read file permissions
 */
static Acl mapPosixFilePermissionToCloudSearchAcl(Path pathToFile) throws IOException {
  // Id of the identity source for external user/group IDs. Shown here,
  // but may be omitted in the SDK as it is automatically applied
  // based on the `api.identitySourceId` configuration parameter.
  String identitySourceId = "abcdef12345";

  // Retrieve the file system permissions for the item being indexed.
  PosixFileAttributeView attributeView = Files.getFileAttributeView(
      pathToFile,
      PosixFileAttributeView.class,
      LinkOption.NOFOLLOW_LINKS);

  if (attributeView == null) {
    // Can't read, return empty ACl
    return new Acl.Builder().build();
  }

  PosixFileAttributes attrs = attributeView.readAttributes();
  // ...
}

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.

FilePermissionSample.java
// Owner, for search quality.
// Note that for principals the name is not the primary
// email address in Cloud Directory, but the local ID defined
// by the OS. Users and groups must be referred to by their
// external ID and mapped via an identity source.
List<Principal> owners = Collections.singletonList(
    Acl.getUserPrincipal(attrs.owner().getName(), identitySourceId)
);

Enfin, l'extrait de code suivant montre comment créer des comptes principaux qui peuvent lire le fichier.

FilePermissionSample.java
// List of users to grant access to
List<Principal> readers = new ArrayList<>();

// Add owner, group, others to readers list if permissions
// exist. For this example, other is mapped to everyone
// in the organization.
Set<PosixFilePermission> permissions = attrs.permissions();
if (permissions.contains(PosixFilePermission.OWNER_READ)) {
  readers.add(Acl.getUserPrincipal(attrs.owner().getName(), identitySourceId));
}
if (permissions.contains(PosixFilePermission.GROUP_READ)) {
  String externalGroupName = attrs.group().getName();
  Principal group = Acl.getGroupPrincipal(externalGroupName, identitySourceId);
  readers.add(group);
}
if (permissions.contains(PosixFilePermission.OTHERS_READ)) {
  Principal everyone = Acl.getCustomerPrincipal();
  readers.add(everyone);
}

Une fois que vous disposez de la liste des lecteurs et des propriétaires, vous pouvez créer la LCA:

FilePermissionSample.java
// Build the Cloud Search ACL. Note that inheritance of permissions
// from parents is omitted. See `setInheritFrom()` and `setInheritanceType()`
// methods on the builder if required by your implementation.
Acl acl = new Acl.Builder()
    .setReaders(readers)
    .setOwners(owners)
    .build();

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:

CreateGroupCommand.java
String namespace = "identitysources/" + idSource;
Group group = new Group()
    .setGroupKey(new EntityKey().setNamespace(namespace).setId(groupId))
    .setDescription("Demo group")
    .setDisplayName(groupName)
    .setLabels(Collections.singletonMap("system/groups/external", ""))
    .setParent(namespace);
try {
  CloudIdentity service = Utils.buildCloudIdentityService();
  Operation createOperation = service.groups().create(group).execute();

  if (createOperation.getDone()) {
    // Note: The response contains the data for a Group object, but as
    // individual fields. To convert to a Group instance, either populate
    // the fields individually or serialize & deserialize to/from JSON.
    //
    // Example:
    // String json = service.getJsonFactory().toString(response);
    // Group createdGroup =  service.getObjectParser()
    //     .parseAndClose(new StringReader(json), Group.class);
    System.out.printf("Group: %s\n",
        createOperation.getResponse().toString());
  } else {
    // Handle case where operation not yet complete, poll for
    // completion. API is currently synchronous and all operations return
    // as completed.
    // ...
  }
} catch (Exception e) {
  System.err.printf("Unable to create group: %s", e.getMessage());
  e.printStackTrace(System.err);
}

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:

FilePermissionSample.java
if (permissions.contains(PosixFilePermission.GROUP_READ)) {
  String externalGroupName = attrs.group().getName();
  Principal group = Acl.getGroupPrincipal(externalGroupName, identitySourceId);
  readers.add(group);
}

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:

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é.