Farklı kimlik sistemlerini senkronize etme

Google Cloud Search'te erişim denetimi, kullanıcının Google Hesabı'na göre yapılır. İçerik dizine eklenirken öğelerdeki tüm erişim kontrol listeleri geçerli Google kullanıcı veya grup kimliklerine (e-posta adresleri) çözümlenmelidir.

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

Yönetici Konsolu kullanılarak oluşturulan kimlik kaynakları, aşağıdaki yöntemlerle kimlik sistemleri arasındaki bu boşluğu doldurmaya yardımcı olur:

• Harici kimlikleri depolamak için özel kullanıcı alanı tanımlama. Bu alan, harici kimliklerin Google Hesabı ile eşleştirilmesi 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, Google Workspace veya Google Cloud Directory'deki kullanıcının birincil e-posta adresi hakkında bilgiye sahip değildir.
• Depo, erişim denetimi için Google Workspace'teki e-posta tabanlı gruplara karşılık gelmeyen gruplar tanımlar.

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

Örnek dağıtım

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

1. depo, SAML kullanılarak onaylanan e-posta adresiyle kullanıcıyı tanımlar. 1. depoda, Google Workspace veya Cloud Directory'deki kullanıcının birincil e-posta adresi hakkında bilgi bulunduğu için kimlik kaynağına gerek yoktur.

2. depo doğrudan şirket içi bir dizinle entegre olur ve kullanıcıyı sAMAccountName özelliğiyle tanımlar. 2. depo, harici kimlik olarak sAMAccountName özelliğini kullandığından 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.

İçerik bağlayıcı oluşturmadan önce kimlik kaynağı oluşturmanız gerekir. Çünkü ACL'ler oluşturmak ve verileri dizine eklemek için kimlik kaynağı kimliğine ihtiyacınız olacaktır. Daha önce de belirtildiği gibi, kimlik kaynağı oluşturduğunuzda Cloud Directory'de özel kullanıcı özelliği de oluşturulur. 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ılır.

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

Kuruluşunuzda 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ı olan ve iki harici kimliği (id1_identity ve id2_identity) olan bir kullanıcının ve bu kimliklerin değerlerinin Cloud Directory'de nasıl göründüğü gösterilmektedir:

Dizin oluşturma için erişim kontrol listeleri (ACL) 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 bir kimliği kullanarak asıl kullanıcılar 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'inde, özelliklerde depolanan harici kimlik (externalUserName) kullanılarak nasıl sahip olan asıl kullanıcılar 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 okuyucuları olan asıl kullanıcıların 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 sahiplerin 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 alınan REST API, asıl kullanıcılar oluşturulurken kimlik için identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID modelini kullanır. Önceki tablolara dönecek olursak, Ann'in id1_identity (SAMAccountName) ile bir ACL oluşturursanız kimlik şu şekilde çözümlenir:

identitysources/id1_identity/users/example/ann

Bu kimliğin tamamına, harici kimlik ile Cloud Directory'de depolanan Google kimlikleri arasında bir köprü sağladığı için kullanıcının ara kimliği adı verilir.

Bir depo için kullanılan erişim kontrol listelerini modelleme hakkında daha fazla bilgi için Erişim Kontrol Listeleri'ne bakın.

Harita grupları

Kimlik kaynakları, ACL'lerde kullanılan gruplar için ad alanı olarak da işlev görür. Bu ad alanı özelliğini yalnızca güvenlik amacıyla kullanılan veya bir depoyla yerel olan gruplar oluşturmak ve eşlemek için 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 kimlik kaynağı kaynak adını grup ad alanı olarak kullanın.

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

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şturma

Grup ACL'si oluşturmak için sağlanan harici bir 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ı

Öğeleri dizine eklemek ve erişim kontrol listeleri oluşturmak için Google dışı harici kimlikleri kullanabilirsiniz ancak kullanıcılar, harici kimlikleri Cloud Directory'deki bir Google kimliğine çözümlenene kadar aramadaki öğeleri göremez. Cloud Directory'nin bir kullanıcının hem Google Kimliği'ni hem de harici kimliklerini bilmesini sağlamanın üç yolu vardır:

• Her bir kullanıcı profilini Yönetici Konsolu üzerinden manuel olarak güncelleme Bu işlem yalnızca birkaç kullanıcı profiliyle 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.
• Kimlik Bağlayıcı SDK'sını kullanarak kimlik bağlayıcı oluşturun. Bu SDK, kimlikleri eşlemek için Directory API'nin kullanımını kolaylaştırır.

Kimlik bağlayıcılar, kurumsal kimliklerdeki (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. Kimlik kaynağı oluşturmanız gerekiyorsa kimlik bağlayıcı oluşturmanız gerekir.

Google Cloud Directory Sync (GCDS), kimlik bağlayıcıya örnek olarak verilebilir. Bu kimlik bağlayıcı, Microsoft'un Active Directory'sindeki kullanıcı ve grup bilgilerini, diğer sistemlerde kimliklerini temsil edebilecek kullanıcı özellikleriyle birlikte Cloud Directory'ye 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 eşlemeyi kullanıcıdan kaldırmaya veya başka bir kullanıcıya yeniden eşlemeye çalışırsanız yeniden dizine ekleme yapana 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.