Bu sayfa, Cloud Translation API ile çevrilmiştir.

Farklı kimlik sistemlerini senkronize etme

Google Cloud Search'teki erişim denetimi, kullanıcının Google hesabını temel alır. İçerik dizine eklenirken öğelerdeki tüm EKL'ler geçerli Google kullanıcı veya grup kimliklerine (e-posta adresleri) çözümlenmelidir.

Çoğu durumda, bir deponun Google hesapları hakkında doğrudan bilgisi yoktur. Bunun yerine kullanıcılar, yerel hesaplarla temsil edilebilir veya her bir hesabı tanımlamak için kullanıcının e-posta adresinden farklı bir kimlik sağlayıcı ve kimlikle birleşik oturum açma yöntemini kullanabilir. Bu kimliğe harici kimlik denir.

Yönetici konsolu kullanılarak oluşturulan Kimlik kaynakları, kimlik sistemleri arasındaki bu boşluğun kapatılmasına yardımcı olmak için şunları yapar:

Harici kimlikleri depolamak için bir özel kullanıcı alanı tanımlama. Bu alan, harici kimlikleri bir Google hesabına çözümlemek için kullanılır.
Bir depo veya kimlik sağlayıcı tarafından yönetilen güvenlik grupları için ad alanı tanımlayın.

Aşağıdaki durumlarda kimlik kaynaklarını kullanın:

Depo, kullanıcının Google Workspace veya Google Cloud Directory'deki birincil e-posta adresini bilmiyor.
Bu depo, Google Workspace'teki e-posta tabanlı gruplara karşılık gelmeyen erişim denetimi grupları tanımlar.

Kimlik kaynakları, dizine eklemeyi kimlik eşlemeden ayırarak dizine ekleme verimliliğini artırır. Bu ayırma, EKL'ler oluştururken ve öğeleri dizine eklerken kullanıcıyı aramayı ertelemenize olanak tanır.

Örnek dağıtım

Şekil 1'de bir kuruluş tarafından hem şirket içi hem de bulut depolarının kullanıldığı bir örnek dağıtım gösterilmektedir. Her depo, kullanıcıları belirtmek için farklı bir harici kimlik türü kullanır.

Depo 1, SAML kullanılarak bildirilen e-posta adresini kullanarak kullanıcıyı tanımlar. Depo 1, kullanıcının Google Workspace veya Cloud Directory'deki birincil e-posta adresini bildiğinden kimlik kaynağına gerek yoktur.

Depo 2, doğrudan şirket içi bir dizinle entegre olur ve kullanıcıyı sAMAccountName özelliğiyle tanımlar. Depo 2, harici kimlik olarak bir sAMAccountName özelliği kullandığından kimlik kaynağı gerekir.

Kimlik kaynağı oluşturma

Bir kimlik kaynağına ihtiyacınız varsa Cloud Search'te kullanıcı kimliklerini eşleme başlıklı makaleyi inceleyin.

EKL'ler oluşturmak ve verileri dizine eklemek için kimlik kaynağı kimliğine ihtiyacınız olacağından, içerik bağlayıcısı oluşturmadan önce bir kimlik kaynağı oluşturmanız gerekir. Daha önce belirtildiği gibi, bir kimlik kaynağı oluşturmak Cloud Directory'de özel kullanıcı özelliği de oluşturur. Deponuzdaki her kullanıcının harici kimliğini kaydetmek için bu özelliği kullanın. Özellik, IDENTITY_SOURCE_ID_identity kuralı kullanılarak adlandırılmıştır.

Aşağıdaki tabloda, biri SAM hesap adlarını (sAMAccountName) harici kimlik olarak, diğeri ise kullanıcı kimliklerini (uid) harici kimlik olarak tutan iki kimlik kaynağı gösterilmektedir.

Kimlik kaynağı	kullanıcı özelliği	harici kimlik
id1	id1_identity	sAMAccountName
id2	id2_identity	uid

Kuruluşunuzdaki bir kullanıcıya atıfta bulunmak amacıyla kullanılan her olası harici kimlik için bir kimlik kaynağı oluşturun.

Aşağıdaki tabloda, Google hesabı ve iki harici kimliği (id1_identity ve id2_identity) olan bir kullanıcının ve bu kullanıcıların değerlerinin Cloud Directory'de nasıl göründüğü gösterilmektedir:

kullanıcı	e-posta	id1_identity	id2_identity
Ayşe	ann@example.com	örnek\ann	1001

Dizine ekleme için EKL oluştururken üç farklı kimliği (Google e-postası, sAMAccountName ve uid) kullanarak aynı kullanıcıya başvuruda bulunabilirsiniz.

Kullanıcı EKL'lerini yazma

Sağlanan bir harici kimlik kullanarak ana hesaplar oluşturmak için getUserPrincpal() yöntemini veya getGroupPrincipal() yöntemini kullanın.

Aşağıdaki örnekte dosya izinlerinin nasıl alınacağı gösterilmektedir. Bu izinler, dosyaya erişimi olan her kullanıcının adını içerir.

FilePermissionSample.java

GitHub'da göster

/**
 * 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();
  // ...
}

Aşağıdaki kod snippet'i, özelliklerde depolanan harici kimliği (externalUserName) kullanan ana hesapların nasıl oluşturulacağını gösterir.

FilePermissionSample.java

GitHub'da göster

// 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)
);

Son olarak, aşağıdaki kod snippet'i dosyanın okuyucusu olan ana hesapların nasıl oluşturulacağını gösterir.

FilePermissionSample.java

GitHub'da göster

// 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);
}

Okuyucu ve sahip listenizi oluşturduktan sonra EKL'yi oluşturabilirsiniz:

FilePermissionSample.java

GitHub'da göster

// 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();

Temel REST API, ana hesapları oluştururken kimlik için identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID kalıbını kullanır. Önceki tablolara dönersek, Ann'in id1_identity (SAMAccountName) nesnesiyle bir EKL oluşturursanız kimlik şu şekilde çözümlenir:

identitysources/id1_identity/users/example/ann

Harici kimlik ile Cloud Directory'de depolanan Google kimlikleri arasında bir köprü görevi gören bu kimliğin tamamına kullanıcının ara kimliği adı verilir.

Bir depoda kullanılan EKL'leri modelleme hakkında daha fazla bilgi için EKL'ler sayfasına bakın.

Grupları eşleyin

Kimlik kaynakları, EKL'lerde kullanılan gruplar için ad alanı görevi de görür. Bu ad alanı özelliğini, yalnızca güvenlik amacıyla kullanılan veya bir depo için yerel olan gruplar oluşturup eşlemek için kullanabilirsiniz.

Grup oluşturmak ve üyelikleri yönetmek için Cloud Identity Groups API'sini kullanın. Grubu bir kimlik kaynağıyla ilişkilendirmek için grup ad alanı olarak kimlik kaynağı adını kullanın.

Aşağıdaki kod snippet'i, Cloud Identity Groups API'yi kullanarak nasıl grup oluşturulacağını gösterir:

CreateGroupCommand.java

GitHub'da göster

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);
}

Grup EKL oluşturma

Grup EKL oluşturmak için getGroupPrincipal() yöntemini kullanarak sağlanan bir harici kimlik kullanarak grup sorumlusu oluşturun. Daha sonra, Acl.Builder sınıfını kullanarak aşağıdaki gibi EKL'yi oluşturun:

FilePermissionSample.java

GitHub'da göster

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

Kimlik bağlayıcıları

EKL'ler oluşturmak ve öğeleri dizine eklemek için harici, Google dışı kimlikleri kullanabilirsiniz. Ancak harici kimlikleri Cloud Directory'de bir Google kimliğine çözümlenene kadar kullanıcılar, aramadaki öğeleri göremez. Cloud Directory'nin bir kullanıcının hem Google kimliğini hem de harici kimliklerini bildiğinden emin olmanın üç yolu vardır:

Her bir kullanıcı profilini Yönetici konsolu aracılığıyla manuel olarak güncelleyin Bu işlem yalnızca birkaç kullanıcı profili kullanarak test ve prototip oluşturma için önerilir.
Directory API'yi kullanarak harici kimlikleri Google kimlikleriyle eşleyin. Bu işlem Identity Connector SDK'sını kullanamayan kişiler için önerilir.
Identity Connector SDK'sını kullanarak bir kimlik bağlayıcısı oluşturun. Bu SDK, kimlikleri eşlemek için Directory API'nin kullanımını basitleştirir.

Kimlik bağlayıcıları, kurumsal kimliklerden (kullanıcılar ve gruplar) harici kimlikleri, Google Cloud Search tarafından kullanılan dahili Google kimliklerine eşlemek için kullanılan programlardır. Bir kimlik kaynağı oluşturmanız gerekiyorsa bir kimlik bağlayıcısı oluşturmanız gerekir.

Google Cloud Directory Sync (GCDS), bir kimlik bağlayıcı örneğidir. Bu kimlik bağlayıcısı, Microsoft Active Directory'deki kullanıcı ve grup bilgilerini diğer sistemlerde temsil edebilecek kullanıcı özellikleriyle birlikte Cloud Directory'ye eşler.

REST API ile kimlik senkronizasyonu

Kimlikleri REST API ile senkronize etmek için update yöntemini kullanın.

Kimlikleri yeniden eşleme

Bir öğenin kimliğini başka bir kimlikle yeniden eşledikten sonra, yeni kimliğin geçerli olması için öğeleri yeniden dizine eklemeniz gerekir. Örneğin,

Bir eşlemeyi bir kullanıcıdan kaldırmaya veya başka bir kullanıcıya yeniden eşlemeye çalışırsanız siz yeniden dizine ekleyene kadar orijinal eşleme korunur.
Bir öğe EKL'de yer alan eşlenmiş bir grubu siler ve daha sonra aynı groupKey ile yeni bir grup oluşturursanız öğe yeniden dizine eklenene kadar yeni grup, öğeye erişim sağlamaz.