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 tüm öğe EKL'leri geçerli Google kullanıcı veya grup kimliklerine (e-posta adresleri) çözümlenmelidir.

Çoğu durumda, bir depo Google Hesapları hakkında doğrudan bilgiye sahip değildir. Bunun yerine, yerel hesaplar kullanıcıları temsil eder veya kullanıcılar bir kimlik sağlayıcıyla federasyon oturum açma özelliğini kullanır. E-posta adresi dışındaki bu tanımlamaya harici kimlik adı verilir.

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

Kimlik kaynaklarını şu durumlarda kullanın:

  • Depo, kullanıcının Google Workspace veya Google Cloud Directory'deki birincil e-posta adresini bilmiyor.
  • 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 verimliliği artırır. Bu, öğeleri dizine eklerken ve erişim kontrol listeleri oluştururken kullanıcı aramayı ertelemenize olanak tanır.

Örnek dağıtım

Şekil 1'de hem şirket içi hem de bulut depolarını kullanan bir işletme gösterilmektedir. Her biri farklı bir harici kimlik türü kullanır.

Farklı kimlik türleriyle örnek kurumsal dağıtım
Şekil 1. Farklı kimlik türleriyle örnek kurumsal dağıtım.

1. depo, kullanıcıları SAML kullanarak e-posta adresine göre tanımlar. Google Workspace veya Cloud Directory'deki birincil e-posta adresini bildiği için kimlik kaynağına ihtiyaç duymaz.

2. depo, şirket içi bir dizinle entegre olur ve kullanıcıları sAMAccountName ile tanımlar. Bu özelliği harici kimlik olarak kullandığı için kimlik kaynağı gerektirir.

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ğını oluşturun. ACL'ler oluşturmak ve verileri dizine eklemek için kimlik kaynağının kimliğine ihtiyacınız vardır. Kimlik kaynağı oluşturduğunuzda, harici kimlikleri depolamak için Cloud Directory'de bir özel kullanıcı özelliği de oluşturulur. Özellik adı, IDENTITY_SOURCE_ID_identity kuralını kullanır.

Bu tabloda iki kimlik kaynağı gösterilmektedir: biri SAM hesap adları, diğeri ise kullanıcı kimlikleri (uid) için.

Kimlik kaynağı Kullanıcı mülkü Harici Kimlik
id1 id1_identity sAMAccountName
id2 id2_identity uid

Kuruluşunuzda kullanılan her harici kimlik türü için bir kimlik kaynağı oluşturun.

Bu tabloda, Google Hesabı olan ve iki harici kimliği bulunan bir kullanıcının Cloud Directory'de nasıl göründüğü gösterilmektedir:

Kullanıcı E-posta id1_identity id2_identity
Ayşe ann@example.com example\ann 1001

Dizin oluşturma için erişim kontrol listeleri (ACL) oluştururken bu kimliklerden herhangi birini kullanarak aynı kullanıcıya başvurabilirsiniz.

Kullanıcı EKL'leri yazma

Harici kimlikleri kullanarak asıl kullanıcılar oluşturmak için getUserPrincipal() veya getGroupPrincipal() kullanın.

Bu örnek, erişimi olan kullanıcılar da dahil olmak üzere dosya izinlerini alır:

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

Bu snippet, externalUserName özelliğini kullanarak sahipler için asıl öğeler oluşturur:

FilePermissionSample.java
// 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)
);

Bu snippet, okuyucular için asıl kullanıcılar oluşturur:

FilePermissionSample.java
// 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 ve sahipler ekledikten sonra ACL'yi oluşturun:

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

REST API, identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID kalıbını kullanır. Ayla'nın id1_identity ifadesi identitysources/id1_identity/users/example/ann olarak çözümlenir. Bu, kullanıcının ara kimliğidir.

Depo EKL'lerini modelleme hakkında daha fazla bilgi için EKL'ler başlıklı makaleyi inceleyin.

Harita grupları

Kimlik kaynakları, ACL grupları için ad alanı olarak da kullanılır. Bunu, yalnızca güvenlik için kullanılan veya yerel olan grupları oluşturmak ve bir depoyla eşlemek için kullanın.

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

Bu snippet bir grup oluşturur:

CreateGroupCommand.java
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

Harici kimliğe sahip bir grup yöneticisi oluşturmak için getGroupPrincipal() kullanın, ardından ACL'yi oluşturun:

FilePermissionSample.java
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ı

Kullanıcılar, harici kimlikleri Cloud Directory'de bir Google Kimliği ile eşleşene kadar arama sonuçlarındaki öğeleri göremez. Bunu üç şekilde sağlayabilirsiniz:

Kimlik bağlayıcıları, kurumsal kimliklerdeki harici kimlikleri dahili Google kimlikleriyle eşler. Bir kimlik kaynağı oluşturursanız kimlik bağlayıcı da oluşturmanız gerekir.

Google Cloud Directory Sync (GCDS), kimlik bağlayıcıya örnek olarak verilebilir. Active Directory'deki kullanıcı ve grup bilgilerini Cloud Directory'ye eşler.

REST API'yi kullanarak kimlikleri senkronize etme

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

Kimlikleri yeniden eşleme

Bir kimliği yeniden eşledikten sonra, değişikliğin geçerlilik kazanması için öğeleri yeniden dizine eklemeniz gerekir.

  • Bir kullanıcı eşlemesini kaldırırsanız veya değiştirirseniz yeniden indeksleme yapılana kadar orijinal eşleme kalır.
  • Eşlenmiş bir grubu silip aynı groupKey ile yeni bir grup oluşturursanız yeniden dizine ekleme yapana kadar erişim izni verilmez.