Farklı kimlik sistemlerini senkronize etme

Google Cloud Search'te erişim denetimi, kullanıcının Google Hesabı'na dayanır. İçerik dizine eklenirken öğelerdeki tüm ACL'ler geçerli Google kullanıcı veya grup kimliklerine (e-posta adresleri) yönlendirilmelidir.

Çoğu durumda, depolar Google hesapları hakkında doğrudan bilgi sahibi değildir. Bunun yerine, kullanıcılar yerel hesaplar tarafından temsil edilebilir veya her hesabı tanımlamak için bir kimlik sağlayıcı ve kullanıcının e-posta adresi dışında bir kimlikle birleşik oturum açma özelliğini kullanabilir. Bu kimliğe harici kimlik denir.

Yönetici Konsolu kullanılarak oluşturulan kimlik kaynakları, kimlik sistemleri arasındaki bu boşluğu kapatmaya yardımcı olur.

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

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

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

Kimlik kaynakları, dizine ekleme işlemini kimlik eşlemeden ayırarak dizine ekleme verimliliğini artırır. Bu ayrıştırma, EKL oluştururken ve öğeleri dizine eklerken kullanıcıyı arama işlemini ertelemenize olanak tanır.

Örnek dağıtım

Şekil 1'de, bir kuruluşun hem şirket içi hem de bulut depolama alanlarını kullandığı örnek bir dağıtım gösterilmektedir. Her depo, kullanıcılara referans vermek için farklı bir harici kimlik türü kullanır.

1. depo, SAML kullanılarak beyan edilen e-posta adresini kullanarak kullanıcıyı tanımlar. 1. depo, Google Workspace veya Cloud Directory'deki kullanıcının 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ğine göre tanımlar. 2. depo, harici kimlik olarak sAMAccountName özelliği kullandığından bir kimlik kaynağı gerekir.

Kimlik kaynağı oluşturma

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

ACL'ler ve dizin verileri oluşturmak 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 de belirtildiği gibi, bir kimlik kaynağı oluşturduğunuzda Cloud Directory'de özel bir kullanıcı özelliği de oluşturulur. Deponuzdan her kullanıcının harici kimliğini kaydetmek için bu özelliği kullanın. Mülk, IDENTITY_SOURCE_ID_identity kuralı kullanılarak adlandırılır.

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

Kuruluşunuzdaki bir kullanıcıya atıfta bulunmak için 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ının değerlerinin Cloud Directory'de nasıl göründüğü gösterilmektedir:

Dizine ekleme için ACL'ler oluştururken üç farklı kimliği (Google e-postası, sAMAccountName ve uid) kullanarak aynı kullanıcıya referans verebilirsiniz.

Kullanıcı EKL'leri yazma

Sağlanan harici kimliği kullanarak yönetici oluşturmak için getUserPrincpal() 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.

/**
 * 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'inde, özelliklerde depolanan harici kimlik (externalUserName) kullanılarak sahip olan kimliklerin nasıl oluşturulacağı gösterilmektedir.

// 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'inde dosyanın okuyucusu olan yöneticilerin nasıl oluşturulacağı gösterilmektedir.

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

Okuyucuların ve sahiplerinin listesini oluşturduktan sonra ACL'yi oluşturabilirsiniz:

// 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, kimliği oluştururken identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID şemasını kullanır. Önceki tablolara dönecek olursak, Ayşe'nin id1_identity (SAMAccountName) ile bir ACL oluşturursanız kimlik şu şekilde çözülür:

identitysources/id1_identity/users/example/ann

Bu kimliğin tamamı, harici kimlik ile Cloud Directory'de depolanan Google kimlikleri arasında köprü görevi gördüğü için kullanıcının ara kimliği olarak adlandırılır.

Bir depo için kullanılan ACL'leri modelleme hakkında daha fazla bilgi için ACL'ler bölümüne bakın.

Harita grupları

Kimlik kaynakları, ACL'lerde kullanılan gruplar için ad alanı olarak da kullanılır. Yalnızca güvenlik amacıyla kullanılan veya bir depoya yerel olan grupları oluşturmak ve eşlemek için bu ad alanı özelliğini kullanabilirsiniz.

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

Aşağıdaki kod snippet'inde, Cloud Identity Groups API kullanılarak nasıl grup oluşturulacağı gösterilmektedir:

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 ACL'si oluşturma

Grup ACL'si oluşturmak için sağlanan harici kimliği kullanarak grup sorumlusu oluşturmak üzere getGroupPrincipal() yöntemini kullanın. Ardından, Acl.Builder sınıfını kullanarak ACL'yi aşağıdaki gibi oluşturun:

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ı

ACL oluşturmak ve öğeleri dizine eklemek için Google dışı harici kimlikleri kullanabilirsiniz. Ancak kullanıcılar, harici kimlikleri Cloud Directory'de bir Google kimliğiyle çözülene kadar aramadaki öğeleri göremez. Cloud Directory'nin bir kullanıcının hem Google kimliğini hem de harici kimliklerini bilmesi için üç yöntem vardır:

• Yönetici Konsolu üzerinden her kullanıcı profilini manuel olarak güncelleyin. Bu işlem yalnızca birkaç kullanıcı profili kullanılarak 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ı kullanamayanlar için önerilir.
• Identity Connector SDK'sını kullanarak bir kimlik bağlayıcı oluşturun. Bu SDK, kimlikleri eşlemek için Directory API'nin kullanımını basitleştirir.

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

Google Cloud Directory Sync (GCDS), kimlik bağlayıcı örneğidir. Bu kimlik bağlayıcı, Microsoft'un Active Directory'sindeki kullanıcı ve grup bilgilerini, diğer sistemlerdeki kimliklerini temsil edebilecek kullanıcı özellikleriyle birlikte Cloud Directory ile eşler.

REST API'yi kullanarak kimlikleri senkronize etme

REST API'yi kullanarak kimlikleri 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 kullanıcıdan eşlemeyi kaldırmaya veya başka bir kullanıcıyla yeniden eşlemeye çalışırsanız yeniden dizine ekleme işlemini gerçekleştirene kadar orijinal eşleme korunur.
• Bir öğe ACL'sinde bulunan eşlenmiş bir grubu silip aynı groupKey ile yeni bir grup oluşturursanız yeni grup, öğe yeniden dizine eklenene kadar öğeye erişim sağlamaz.