Farklı kimlik sistemlerini senkronize etme

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

Çoğu durumda ilgili depo, Google Hesaplarına dair doğrudan bilgiye sahip olmaz. Bunun yerine, kullanıcılar yerel hesaplarla temsil edilebilir veya her bir hesabı tanımlamak için, bir kimlik sağlayıcı ve kimlikle (kullanıcının e-posta adresi dışında) birleşik oturum açma özelliğini kullanabilirler. Bu kimliğe harici kimlik denir.

Yönetici Konsolu kullanılarak oluşturulan Kimlik kaynakları, aşağıdakileri yaparak kimlik sistemleri arasındaki bu boşluğun kapatılmasına yardımcı olur:

• Harici kimlikleri depolamak için özel kullanıcı alanı tanımlama. 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 bir 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 adresiyle ilgili bilgiye sahip değildir.
• Depo, Google Workspace'teki e-posta tabanlı gruplara karşılık gelmeyen erişim denetimi gruplarını tanımlar.

Kimlik kaynakları, dizine ekleme işlemini kimlik eşlemeden ayırarak dizine ekleme verimliliğini artırır. Bu ayırma, EKL'ler oluşturma ve öğeleri dizine ekleme işlemleri sırasında 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ılara referans vermek için farklı bir harici kimlik kullanır.

1. Depo, kullanıcıyı SAML kullanılarak iddia edilen e-posta adresini kullanarak tanımlar. 1. depo, Google Workspace veya Cloud Directory'de kullanıcının birincil e-posta adresini bildiğinden kimlik kaynağı gerekmez.

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 sAMAccountName özelliğini kullandığından bir 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 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 belirtildiği gibi, kimlik kaynağı oluşturmak Cloud Directory'de özel kullanıcı özelliği de oluşturur. Deponuzdaki her bir 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 iki kimlik kaynağı gösterilmektedir. Biri SAM hesap adlarını (sAMAccountName) harici kimlik, diğeri ise kullanıcı kimliklerini (uid) harici kimlik olarak tutmak için kullanılır.

Kuruluşunuzdaki bir kullanıcıya referans vermek üzere 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ılara ait değerlerin Cloud Directory'de nasıl göründüğü gösterilmektedir:

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

Kullanıcı EKL'lerini yazma

Sağlanan bir harici kimliği 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.

/**
 * 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 sahip ana hesapların nasıl oluşturulacağını gösterir.

// 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 okuyucuları olan ana hesapların nasıl oluşturulacağını gösterir.

// 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 sahiplerin listesini edindikten sonra EKL'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, ana hesapları oluştururken kimlik için identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID kalıbını kullanır. Önceki tablolara dönecek olursak, Ayşe'nin id1_identity (SAMAccountName) ile 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ü sağladığı için bu kimliğin tamamına kullanıcının ara kimliği denir.

Bir depoda kullanılan EKL'lerin modellenmesi hakkında daha fazla bilgi için EKL'ler bölümüne bakın.

Harita grupları

Kimlik kaynakları, EKL'lerde kullanılan gruplar için ad alanı görevi de görür. Yalnızca güvenlik amacıyla kullanılan veya bir depoda 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ı olarak kimlik kaynağı kaynak adını kullanın.

Aşağıdaki kod snippet'inde, Cloud Identity Groups API'yi kullanarak 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 EKL'si oluştur

Grup EKL'si oluşturmak için getGroupPrincipal() yöntemini kullanarak sağlanan harici bir kimliği kullanarak grup ana hesabı oluşturun. Ardından aşağıdaki gibi Acl.Builder sınıfını kullanarak EKL'yi 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ı

EKL'ler oluşturmak ve öğeleri dizine eklemek için Google dışı harici kimlikler kullanabilirsiniz. Ancak kullanıcılar, harici kimlikleri Cloud Directory'de bir Google kimliğine karşılık gelene kadar aramadaki öğeleri göremez. Cloud Directory'nin kullanıcının hem Google kimliğini hem de harici kimliklerini bilmesini sağlamanın üç yolu vardır:

• Her bir kullanıcı profilini Yönetici Konsolu üzerinden manuel olarak güncelleyin Bu işlem yalnızca birkaç kullanıcı profili kullanarak test ve prototip oluşturmak için önerilir.
• Directory API'yi kullanarak harici kimlikleri Google kimlikleriyle eşleyin. Bu işlem, Identity Connector SDK'sını kullanamayan kullanıcılar 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 kimlikleriyle eşlemek için kullanılan programlardır. Bir kimlik kaynağı oluşturmanız gerekiyorsa kimlik bağlayıcısı oluşturmanız gerekir.

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

REST API kullanarak kimlikleri senkronize etme

REST API 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 siz yeniden dizine ekleyene kadar orijinal eşleme korunur.
• Bir öğe EKL'sinde bulunan eşlenmiş bir grubu siler ve ardından aynı groupKey ile yeni bir grup oluşturursanız yeni grup, öğe yeniden dizine eklenene kadar öğeye erişim sağlamaz.