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ısı veya grup kimlikleri (e-posta adresleri).

Çoğu durumda depo hizmeti Google’ın bilgi birikimine sahip olmaz hesaplar. Bunun yerine kullanıcılar yerel hesaplarla temsil edilir veya bir kimlik sağlayıcı ve kimlikle birleşik oturum açma, diğer kullanıcı e-posta adresinden daha iyi olarak belirleyebilirsiniz. Bu kimliğe harici kimlikten kaldırın.

Yönetici Konsolu kullanılarak oluşturulan Kimlik kaynakları, projeyle ilgili tüm kullanıcıların kimlik sistemlerini sağlayan:

• Özel kullanıcı alanı tanımlama harici kimliklerin depolanmasını sağlar. Alan, harici kimlikleri bir Google Hesabı'na çözümlemek için kullanılır hesap.
• Güvenlik grupları için ad alanı tanımlayın veya mevcut bir kod deposu tarafından kimlik sağlayıcı.

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

• Depo, şuranın birincil e-posta adresini bilmiyor: Google Workspace veya Google Cloud Directory'de kullanıcıyla paylaşabilirsiniz.
• Depo, erişim denetimi için birbiriyle uyumlu olmayan grupları tanımlar Google Workspace'teki e-posta tabanlı gruplar.

Kimlik kaynakları, dizine ekleme işlemini ayrıştırarak dizine ekleme verimliliğini artırır izin verir. Bu ayırma, kullanıcının arama süresini ertelemenize olanak tanır. göz önünde bulundurun.

Örnek dağıtım

Şekil 1'de hem şirket içi hem bulut tabanlı bir dağıtım olan örnek bir kuruluş tarafından kullanılır. Her depo farklı bir tür kullanır harici kimliğin bir listesidir.

Kod Deposu 1, kullanıcıyı SAML. Çünkü kullanıcının birincil e-posta adresini bildiğinden emin olun. Google Workspace veya Cloud Directory kullanıyorsanız kimlik kaynağı gerekmez.

Kod deposu 2, şirket içi bir dizinle doğrudan entegre olur ve kullanıcıyı sAMAccountName özelliğine göre tanımlar. Çünkü depo 2 harici kimlik olarak bir sAMAccountName özelliği kullanıyorsa, 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.

İçerik bağlayıcısı oluşturmadan önce bir kimlik kaynağı oluşturmanız gerekir. EKL'ler oluşturmak ve verileri dizine eklemek için kimlik kaynağı kimliğine ihtiyacınız vardır. Bahsedildiği gibi Önceden bir kimlik kaynağı oluşturmak, özel kullanıcı özelliği Cloud Directory'de bulabilirsiniz. Her bir öğenin harici kimliğini kaydetmek için bu özelliği kullanın arasında yer alır. Mülk, IDENTITY_SOURCE_ID_identity.

Aşağıdaki tabloda, biri SAM hesap adlarını muhafaza eden iki kimlik kaynağı gösterilmektedir (sAMAccountName) içeren bir hesap oluşturun.

Kullanılan her olası harici kimlik için bir kimlik kaynağı oluşturun kuruluşunuzdaki bir kullanıcıya atıfta bulunun.

Aşağıdaki tabloda, Google Hesabı ve iki harici kimliği olan bir kullanıcının (id1_identity ve id2_identity) ile bunların değerleri Cloud Directory'de görünür:

Üç farklı kimlik kullanarak aynı kullanıcıya referansta bulunabilirsiniz. (Google e-posta adresi, sAMAccountName ve uid) dizine ekleme için EKL'leri oluştururken.

Kullanıcı EKL'lerini yazma

Şunu kullanın: getUserPrincpal() yöntemini veya getGroupPrincipal() yöntemini kullanarak ana hesap oluşturma yöntemini kullanabilirsiniz.

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, sahip olan ana hesapların nasıl oluşturulacağını gösterir özelliklerde depolanan harici kimlik (externalUserName) kullanılarak.

// 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ıdır.

// 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, kalıbı kullanır identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID. kimlik için geçerlidir. Önceki tablolara dönecek olursak, Ayşe'nin id1_identity hesabı (SAMAccountName) ile bir EKL oluşturursanız kimlik şu değere çözümle:

identitysources/id1_identity/users/example/ann

Bu kimliğin tamamına, kullanıcının ara kimliği denir. Çünkü harici kimlik ile depolanan Google kimlikleri arasında bir köprü sağlar Google Cloud Directory'yi kullanabilirsiniz.

Bir depoda kullanılan ACL'lerin modellenmesi hakkında daha fazla bilgi için bkz. ACL'ler.

Harita grupları

Kimlik kaynakları, EKL'lerde kullanılan gruplar için ad alanı görevi de görür. Şunları yapabilirsiniz: güvenlik amacıyla kullanılan gruplar oluşturmak ve eşlemek için bu ad alanı özelliğini kullanın veya depoda yerel olan uygulamalardır.

Cloud Identity Groups API'yi kullanma seçeneğini tıklayın. Grubu bir kullanıcıyla ilişkilendirmek için kimlik kaynağı varsa grup ad alanı olarak kimlik kaynağı kaynağı adını kullanın.

Aşağıdaki kod snippet'i, Cloud Identity Groups API:

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 oluşturmak için getGroupPrincipal() yöntemini kullanabilirsiniz. Ardından, Acl.Builder sınıfını şu şekilde tanımlar:

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. kullanıcılar, harici kimlikleri bir Google aramasıyla çözülene kadar bir aramadaki öğeleri göremez Cloud Directory'deki kimliği. Paydaş analizine hazırlanırken Cloud Directory kullanıcının hem Google kimliğini hem de harici kimliklerini bilir:

• 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.
• Kimlik bağlayıcısı oluşturma her bir arama terimi için Identity Connector SDK'sı. Bu SDK, kimlikleri eşlemek için Directory API'nin kullanımını basitleştirir.

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

Google Cloud Directory Sync (GCDS): örneğini inceleyelim. Bu kimlik bağlayıcısı, kullanıcı ve Microsoft Active Directory'den Cloud Directory'ye de diğer sistemlerde kimliklerini temsil edebilecek kullanıcı özellikleriyle

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 öğeleri yeniden dizine eklemeniz gerekir yeni kimliğin önemini korur. Örneğin,

• Bir kullanıcıdan eşlemeyi kaldırmaya veya başka bir kullanıcıyla yeniden eşlemeye çalışırsanız orijinal eşleme siz yeniden dizine ekleyene kadar korunur.
• Bir öğe EKL'sinde bulunan eşlenmiş bir grubu siler ve ardından bir yeni grup aynı groupKey değerine sahipse yeni grup bu öğeye geri dönülür.