Synchroniser différents systèmes d'identité

Dans Google Cloud Search, le contrôle d'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éé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 utilisateur personnalisé pour stocker les ID externes. Ce champ est utilisé pour associer les ID externes à 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 à des groupes de messagerie 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 montre un exemple de déploiement où des dépôts sur site et dans le cloud sont utilisés par une entreprise. 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. Comme le dépôt 1 connaît l'adresse e-mail principale de l'utilisateur dans Google Workspace ou l'annuaire cloud, aucune source d'identité n'est nécessaire.

Le dépôt 2 s'intègre directement à un répertoire sur site et identifie l'utilisateur par son attribut sAMAccountName. Comme 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 Mapper les identités des utilisateurs 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 des 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 à l'aide de la convention

IDENTITY_SOURCE_ID_identity

Le tableau suivant présente deux sources d'identité : l'une pour les noms de compte SAM (sAMAccountName) en tant qu'ID externes et l'autre pour les ID utilisateur (uid) en tant qu'ID externes.

Créez une source d'identité pour chaque possible ID externe utilisé pour 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:

Vous pouvez référencer le même utilisateur en utilisant les trois ID différents (adresse e-mail Google, sAMAccountName et uid) lors de la création des LCA pour l'indexation.

Modifier les LCA utilisateur

Utilisez les méthodes getUserPrincpal() ou getGroupPrincipal() pour créer des comptes principaux à l'aide de l'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.

/**
 * 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 propriétaires à l'aide de l'ID externe (externalUserName) stocké dans les attributs.

// 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 sont lecteurs du fichier.

// 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 d'une liste de lecteurs et de propriétaires, vous pouvez créer la LCA:

// 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 format

identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID

identitysources/id1_identity/users/example/ann

Cet ID entier est appelé ID intermédiaire, car il fournit un pont entre l'ID externe et les ID Google stockés dans Cloud Directory.

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 qui ne sont utilisés qu'à des fins de sécurité ou qui sont locaux à un dépôt.

Utilisez l'API Cloud Identity Groups pour créer un groupe et gérer les membres. Pour associer le groupe à une source d'identité, utilisez le nom de 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:

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, créez un compte principal de groupe à l'aide de l'ID externe fourni à l'aide de la méthode getGroupPrincipal(). Ensuite, créez la LCA à l'aide de la classe Acl.Builder comme suit:

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, n'appartenant pas à 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 leur ID externe ne correspond pas à un ID Google dans l'annuaire cloud. Il existe trois manières de s'assurer que l'annuaire cloud connaît à la fois l'ID Google et les ID externes d'un utilisateur:

• Mettre à jour chaque profil utilisateur manuellement via la console d'administration Ce processus n'est recommandé que pour les tests et le prototypage avec quelques profils utilisateur.
• Mapper des ID externes avec des ID Google à l'aide de l'API Directory Cette procédure est recommandée pour ceux qui ne peuvent 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 utilisés pour mapper des ID externes d'identités d'entreprise (utilisateurs et groupes) à des 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 l'annuaire Active Directory de Microsoft avec 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.

Remapper 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, le mappage d'origine est conservé jusqu'à ce que vous le réindexiez.
• Si vous supprimez un groupe mappé présent dans une liste de contrôle d'accès, puis 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'a pas été réindexé.