Google Cloud Search में ऐक्सेस कंट्रोल, उपयोगकर्ता के Google खाते पर आधारित होता है. कॉन्टेंट को इंडेक्स करते समय, आइटम पर मौजूद सभी ACL का एक मान्य Google उपयोगकर्ता के तौर पर समाधान होना चाहिए या ग्रुप आईडी (ईमेल पते).
कई मामलों में डेटा स्टोर करने की जगह को Google की सीधी जानकारी नहीं होती खाते. इसके बजाय, उपयोगकर्ताओं को स्थानीय खातों से दिखाया जा सकता है या इनका इस्तेमाल किया जा सकता है किसी आइडेंटिटी प्रोवाइडर और आईडी की मदद से, फ़ेडरेटेड साइन-इन की सुविधा का इस्तेमाल करना का इस्तेमाल करें. इस आईडी को बाहरी आईडी.
Admin console का इस्तेमाल करके बनाया गया. पहचान सोर्स की मदद से, GA4 प्रॉपर्टी के बीच के अंतर को कम किया जा सकता है पहचान करने वाले सिस्टम:
- कस्टम उपयोगकर्ता फ़ील्ड तय करना का इस्तेमाल करें. बाहरी आईडी का समाधान Google से करने के लिए, इस फ़ील्ड का इस्तेमाल किया जाता है जोड़ें.
- सुरक्षा से जुड़े ग्रुप के लिए नाम स्थान तय करें डेटा स्टोर करने की जगह से मैनेज किया जाता है या आइडेंटिटी प्रोवाइडर.
पहचान स्रोतों का इस्तेमाल तब करें, जब:
- डेटा स्टोर करने की जगह को इसके मुख्य ईमेल पते की जानकारी नहीं है Google Workspace या Google Cloud डायरेक्ट्री के उपयोगकर्ता हैं.
- रिपॉज़िटरी, ऐक्सेस कंट्रोल के लिए ऐसे ग्रुप के बारे में बताती है जो आपस में मेल नहीं खाते शामिल हैं.
पहचान के सोर्स, इंडेक्स करने की प्रोसेस को अलग करके, इंडेक्स करने की क्षमता को बेहतर बनाते हैं को हटा दिया जाता है. इस डीकपलिंग की मदद से, उपयोगकर्ता को कुछ समय तक देखे जाने से रोका जा सकता है ACL और आइटम इंडेक्स करते समय.
डिप्लॉयमेंट का उदाहरण
पहली इमेज में डिप्लॉयमेंट का ऐसा उदाहरण दिखाया गया है जिसमें कंपनी की इमारत और क्लाउड, दोनों जगह लागू होती है डेटा स्टोर करने की जगहों का इस्तेमाल कोई एंटरप्राइज़ करता है. डेटा स्टोर करने की हर जगह के लिए एक अलग टाइप का बाहरी आईडी का इस्तेमाल करें.
![डिप्लॉयमेंट का उदाहरण](https://developers-dot-devsite-v2-prod.appspot.com/static/cloud-search/images/identity-arch.png?authuser=4&hl=hi)
डेटा स्टोर करने की जगह 1, उपयोगकर्ता के उस ईमेल पते की पहचान करती है जिस पर दावा किया गया है SAML. क्योंकि डेटा स्टोर करने की जगह 1 के पास, इसमें उपयोगकर्ता के मुख्य ईमेल पते की जानकारी है Google Workspace या Cloud डायरेक्ट्री में, पहचान के सोर्स की ज़रूरत नहीं होती.
डेटा स्टोर करने की जगह 2 सीधे कंपनी की इमारत में मौजूद डायरेक्ट्री के साथ इंटिग्रेट हो जाती है और
उपयोगकर्ता की पहचान उसके sAMAccountName
एट्रिब्यूट से करता है. क्योंकि रिपॉज़िटरी 2
sAMAccountName
एट्रिब्यूट का इस्तेमाल बाहरी आईडी के तौर पर करता है. पहचान स्रोत
की ज़रूरत नहीं है.
पहचान स्रोत बनाएं
अगर आपको किसी आइडेंटिटी सोर्स की ज़रूरत है, तो Cloud Search में उपयोगकर्ता की पहचान को मैप करना लेख पढ़ें.
कॉन्टेंट कनेक्टर बनाने से पहले आपको एक आइडेंटिटी सोर्स बनाना होगा, क्योंकि
आपको ACL और इंडेक्स डेटा बनाने के लिए पहचान स्रोत आईडी की ज़रूरत होगी. जैसा बताया गया है
पहले, आइडेंटिटी सोर्स बनाने से
कस्टम उपयोगकर्ता प्रॉपर्टी
क्लाउड डायरेक्ट्री में मौजूद हैं. हर प्रॉपर्टी का बाहरी आईडी रिकॉर्ड करने के लिए, यह प्रॉपर्टी इस्तेमाल करें
उपयोगकर्ता को जोड़ा जा सकता है. प्रॉपर्टी को नाम देने के लिए,
कन्वेंशन IDENTITY_SOURCE_ID_identity
.
इस टेबल में दो आइडेंटिटी सोर्स दिखाए गए हैं. इनमें से एक में एसएएम खाते का नाम होना चाहिए (sAMAccountName) को बाहरी आईडी के रूप में और एक यूज़र आईडी (uid) को बाहरी आईडी के रूप में रखने के लिए.
पहचान स्रोत | उपयोगकर्ता प्रॉपर्टी | बाहरी आईडी |
---|---|---|
id1 | id1_identity | sAMAccountName |
id2 | id2_identity | uid |
हर उस संभावित बाहरी आईडी के लिए एक आइडेंटिटी सोर्स बनाएं जिसका इस्तेमाल इन कामों के लिए किया जाता है आपके एंटरप्राइज़ के उपयोगकर्ता को रेफ़र करता है.
नीचे दी गई टेबल में बताया गया है कि कैसे एक उपयोगकर्ता के पास एक Google खाता और दो बाहरी आईडी हैं (id1_identity और id2_identity) और उनकी वैल्यू क्लाउड डायरेक्ट्री में दिखती हैं:
उपयोगकर्ता | ईमेल | id1_identity | id2_identity |
---|---|---|---|
आरती | ann@example.com | उदाहरण\ann | 1001 |
एक ही उपयोगकर्ता का रेफ़रंस देने के लिए, तीन अलग-अलग आईडी, (Google ईमेल, sAMAccountName, और uid).
उपयोगकर्ता ACL लिखें
इसका इस्तेमाल करें getUserPrincpal() तरीका या getGroupPrincipal() दी गई बाहरी आईडी का इस्तेमाल करके, मुख्य खाते बनाने का तरीका.
यहां दिए गए उदाहरण में, फ़ाइल की अनुमतियां वापस पाने का तरीका बताया गया है. ये अनुमतियों में हर उस उपयोगकर्ता का नाम शामिल होता है जिसके पास फ़ाइल का ऐक्सेस है.
नीचे दिया गया कोड स्निपेट, मुख्य खाते बनाने का तरीका बताता है जो मालिक हैं
एट्रिब्यूट में स्टोर किए गए बाहरी आईडी (externalUserName
) का इस्तेमाल करके.
अंत में, नीचे दिया गया कोड स्निपेट ऐसे मुख्य खाते बनाने का तरीका बताता है जो फ़ाइल के पाठक हैं.
आपके पास पाठकों और मालिकों की सूची बनाने के बाद, ACL बना सकते हैं:
मौजूदा REST API, पैटर्न का इस्तेमाल करता है
identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
आईडी के लिए, मुख्य खाता बनाते समय. पिछली टेबल पर वापस जाएं.
अगर आप Ann के id1_identity
(SAMAccountName) के साथ ACL बनाते हैं, तो आईडी
इसका समाधान करें:
identitysources/id1_identity/users/example/ann
इस पूरे आईडी को उपयोगकर्ता का बीच का आईडी कहा जाता है क्योंकि यह बाहरी आईडी और संग्रहित Google आईडी के बीच एक कनेक्शन उपलब्ध कराता है पर जाकर क्लाउड निर्देशिका के साथ साइन इन करें.
डेटा स्टोर करने की जगह के लिए इस्तेमाल किए जाने वाले ACL को मॉडल करने के बारे में ज़्यादा जानकारी के लिए, यह देखें ACL.
मैप के ग्रुप
पहचान के सोर्स, एसीएल में इस्तेमाल किए जाने वाले ग्रुप के लिए नेमस्पेस के तौर पर भी काम करते हैं. आप इस नेमस्पेस सुविधा का इस्तेमाल करके, सुरक्षा के लिए इस्तेमाल किए जाने वाले ग्रुप और मैप ग्रुप बनाएं का इस्तेमाल किया जा सकता है या डेटा स्टोर करने की जगह के लिए स्थानीय है.
Cloud Identity Groups API का इस्तेमाल करना एक समूह बनाने और सदस्यताओं को प्रबंधित करने के लिए. समूह को किसी पहचान स्रोत, ग्रुप नेमस्पेस के तौर पर पहचान स्रोत संसाधन के नाम का इस्तेमाल करें.
नीचे दिया गया कोड स्निपेट दिखाता है कि Cloud Identity Groups API:
समूह ACL बनाएं
समूह ACL बनाने के लिए, इसका उपयोग करें getGroupPrincipal() दी गई बाहरी आईडी का इस्तेमाल करके, ग्रुप मुख्य खाते बनाने का तरीका. इसके बाद, ACL Acl.Builder क्लास का नाम डालें:
आइडेंटिटी कनेक्टर
एसीएल और इंडेक्स आइटम बनाने के लिए, Google से बाहर के आईडी का इस्तेमाल किया जा सकता है. हालांकि, उपयोगकर्ता खोज में तब तक आइटम नहीं देख सकते, जब तक कि उनके बाहरी आईडी का Google में समाधान नहीं हो जाता क्लाउड डायरेक्ट्री में आईडी. यह पक्का करने के तीन तरीके हैं कि क्लाउड डायरेक्ट्री के पास किसी उपयोगकर्ता के Google आईडी और बाहरी आईडी, दोनों की जानकारी होती है:
- Admin console का इस्तेमाल करके, उपयोगकर्ता की हर प्रोफ़ाइल को मैन्युअल तरीके से अपडेट करें इस प्रक्रिया का सुझाव सिर्फ़ कुछ उपयोगकर्ता प्रोफ़ाइलों का इस्तेमाल करके टेस्ट और प्रोटोटाइप बनाने के लिए दिया जाता है.
- Directory API का इस्तेमाल करके Google आईडी पर बाहरी आईडी मैप करें. यह प्रोसेस उन लोगों को इस्तेमाल करने का सुझाव दिया जाता है जो Identity कनेक्टर SDK टूल का इस्तेमाल नहीं कर सकते.
- पहचान कनेक्टर बनाना इसका इस्तेमाल करके Identity Connector SDK टूल. यह SDK टूल, आईडी को मैप करने के लिए Directory API के इस्तेमाल को आसान बनाता है.
आइडेंटिटी कनेक्टर ऐसे प्रोग्राम हैं जिनका इस्तेमाल एंटरप्राइज़ से बाहरी आईडी को मैप करने के लिए किया जाता है Google की ओर से इस्तेमाल की जाने वाली Google की अंदरूनी पहचान से जुड़ी पहचान (उपयोगकर्ता और ग्रुप) Cloud Search. अगर आपको कोई आइडेंटिटी सोर्स बनाना है, तो एक आइडेंटिटी कनेक्टर बनाएं.
Google Cloud डायरेक्ट्री सिंक (जीसीडीएस) आइडेंटिटी कनेक्टर का उदाहरण. यह आइडेंटिटी कनेक्टर, उपयोगकर्ताओं और Microsoft की Active Directory से क्लाउड डायरेक्ट्री में मौजूद ग्रुप की जानकारी उपयोगकर्ता एट्रिब्यूट के साथ होता है जो दूसरे सिस्टम में उनकी पहचान को दिखा सकता है.
REST API का इस्तेमाल करके पहचान फ़ाइलें सिंक करें
REST API का इस्तेमाल करके, पहचानों को सिंक करने के लिए update
तरीके का इस्तेमाल करें.
पहचान फिर से मैप की जा रही हैं
किसी आइटम की पहचान को फिर से मैप करने के बाद, आपको आइटम को फिर से इंडेक्स करना होगा ताकि नई पहचान को रोका जा सके. उदाहरण के लिए,
- अगर आप किसी उपयोगकर्ता से मैपिंग हटाने या इसे किसी दूसरे उपयोगकर्ता पर फिर से मैप करने की कोशिश करते हैं, तो फिर से इंडेक्स करने तक, ओरिजनल मैपिंग को सुरक्षित रखा जाता है.
- अगर आइटम ACL में मौजूद मैप किए गए किसी ग्रुप को मिटाया जाता है. इसके बाद,
उसी
groupKey
वाले नए ग्रुप से जुड़ा है, तो नया ग्रुप जब तक आइटम को फिर से इंडेक्स नहीं किया जाता.