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.
![Örnek dağıtım](https://developers-dot-devsite-v2-prod.appspot.com/static/cloud-search/images/identity-arch.png?authuser=19&hl=tr)
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
kullanıcınız olacak. 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.
Kimlik kaynağı | kullanıcı özelliği | harici kimlik |
---|---|---|
id1 | id1_identity | sAMAccountName |
id2 | id2_identity | uid |
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:
kullanıcı | e-posta | id1_identity | id2_identity |
---|---|---|---|
Ayşe | ann@example.com | örnek\ann | 1001 |
Üç 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.
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.
Son olarak, aşağıdaki kod snippet'i dosyanın okuyucularıdır.
Okuyucu ve sahiplerin listesini edindikten sonra EKL'yi oluşturabilirsiniz:
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:
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:
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.