Google Cloud Search में ऐक्सेस कंट्रोल, उपयोगकर्ता के Google खाते पर आधारित होता है. कॉन्टेंट को इंडेक्स करते समय, सभी आइटम की एसीएल, मान्य Google उपयोगकर्ता या ग्रुप आईडी (ईमेल पते) के तौर पर हल होनी चाहिए.
कई मामलों में, रिपॉज़िटरी को Google खातों के बारे में सीधे तौर पर जानकारी नहीं होती है. इसके बजाय, लोकल खाते उपयोगकर्ताओं के लिए होते हैं या उपयोगकर्ता, पहचान देने वाली कंपनी के साथ फ़ेडरेटेड साइन-इन का इस्तेमाल करते हैं. ईमेल पते के अलावा, इस पहचान को बाहरी आईडी कहा जाता है.
Admin console का इस्तेमाल करके बनाए गए पहचान के सोर्स, पहचान के सिस्टम के बीच के अंतर को कम करते हैं. इसके लिए, वे ये काम करते हैं:
- बाहरी आईडी सेव करने के लिए, कस्टम यूज़र फ़ील्ड तय करना. यह फ़ील्ड, बाहरी आईडी को Google खाते से जोड़ता है.
- किसी रिपॉज़िटरी या पहचान देने वाली सेवा से मैनेज किए जाने वाले सुरक्षा ग्रुप के लिए नेमस्पेस तय करना.
पहचान के सोर्स का इस्तेमाल तब करें, जब:
- रिपॉज़िटरी को Google Workspace या Google Cloud Directory में मौजूद उपयोगकर्ता के मुख्य ईमेल पते के बारे में जानकारी नहीं है.
- डेटाबेस में ऐसे ऐक्सेस कंट्रोल ग्रुप तय किए गए हैं जो Google Workspace में ईमेल पते के आधार पर बनाए गए ग्रुप से मेल नहीं खाते.
आइडेंटिटी सोर्स, इंडेक्सिंग को आइडेंटिटी मैपिंग से अलग करके, बेहतर तरीके से काम करते हैं. इससे, एएलसी बनाते समय और आइटम इंडेक्स करते समय, उपयोगकर्ता की जानकारी को बाद में देखने की सुविधा मिलती है.
डिप्लॉयमेंट का उदाहरण
पहले फ़िगर में, एक एंटरप्राइज़ को कंपनी की इमारत में और क्लाउड, दोनों तरह की रिपॉज़िटरी का इस्तेमाल करते हुए दिखाया गया है. इनमें से हर एक, अलग-अलग तरह के बाहरी आईडी का इस्तेमाल करता है.
Repository 1, एसएएमएल का इस्तेमाल करके उपयोगकर्ताओं की पहचान उनके ईमेल पते से करता है. इसे Google Workspace या Cloud Directory में मौजूद मुख्य ईमेल पते के बारे में पता होता है. इसलिए, इसे पहचान के स्रोत की ज़रूरत नहीं होती.
Repository 2, कंपनी की इमारत में डायरेक्ट्री के साथ इंटिग्रेट होती है और उपयोगकर्ताओं की पहचान sAMAccountName के हिसाब से करती है. इस एट्रिब्यूट का इस्तेमाल बाहरी आईडी के तौर पर किया जाता है. इसलिए, इसके लिए आइडेंटिटी सोर्स की ज़रूरत होती है.
पहचान स्रोत बनाना
अगर आपको पहचान के सोर्स की ज़रूरत है, तो Cloud Search में उपयोगकर्ता की पहचान मैप करना लेख पढ़ें.
कॉन्टेंट कनेक्टर बनाने से पहले, आइडेंटिटी सोर्स बनाएं. आपको एसीएल बनाने और डेटा को इंडेक्स करने के लिए, इसके आईडी की ज़रूरत होगी. पहचान का सोर्स बनाने पर, Cloud Directory में एक कस्टम उपयोगकर्ता प्रॉपर्टी भी बन जाती है. इसका इस्तेमाल बाहरी आईडी को सेव करने के लिए किया जाता है. प्रॉपर्टी के नाम में IDENTITY_SOURCE_ID_identity कन्वेंशन का इस्तेमाल किया गया है.
इस टेबल में पहचान के दो सोर्स दिखाए गए हैं: एक SAM खाते के नामों के लिए और दूसरा उपयोगकर्ता आईडी (यूआईडी) के लिए.
| पहचान स्रोत | उपयोगकर्ता प्रॉपर्टी | बाहरी आईडी |
|---|---|---|
id1 |
id1_identity |
sAMAccountName |
id2 |
id2_identity |
uid |
अपने एंटरप्राइज़ में इस्तेमाल किए गए हर तरह के बाहरी आईडी के लिए, एक आइडेंटिटी सोर्स बनाएं.
इस टेबल में दिखाया गया है कि Google खाते और दो बाहरी आईडी वाला उपयोगकर्ता, Cloud Directory में कैसा दिखता है:
| उपयोगकर्ता | ईमेल | id1_identity |
id2_identity |
|---|---|---|---|
| आरती | ann@example.com |
example\ann |
1001 |
इंडेक्सिंग के लिए एसीएल बनाते समय, इनमें से किसी भी आईडी का इस्तेमाल करके एक ही उपयोगकर्ता को रेफ़र किया जा सकता है.
उपयोगकर्ता के एसीएल लिखना
बाहरी आईडी का इस्तेमाल करके प्रिंसिपल बनाने के लिए, getUserPrincipal() या getGroupPrincipal() का इस्तेमाल करें.
इस उदाहरण में, फ़ाइल की अनुमतियां वापस पाई जाती हैं. इसमें वे उपयोगकर्ता भी शामिल हैं जिनके पास फ़ाइल का ऐक्सेस है:
इस स्निपेट में, externalUserName एट्रिब्यूट का इस्तेमाल करके, मालिकों के लिए प्रिंसिपल बनाए जाते हैं:
इस स्निपेट से, लोगों के लिए प्रिंसिपल बनाए जाते हैं:
रीडर और मालिक तय करने के बाद, एसीएल बनाएं:
REST API, identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID पैटर्न का इस्तेमाल करता है.
ऐन का id1_identity बदलकर identitysources/id1_identity/users/example/ann हो जाता है. यह उपयोगकर्ता का इंटरमीडिएट आईडी है.
रिपॉज़िटरी के लिए ACL मॉडल बनाने के बारे में ज़्यादा जानने के लिए, ACL देखें.
ग्रुप मैप करना
पहचान के सोर्स, ACL ग्रुप के लिए नेमस्पेस के तौर पर भी काम करते हैं. इसका इस्तेमाल, सिर्फ़ सुरक्षा या किसी रिपॉज़िटरी के लिए इस्तेमाल किए जाने वाले ग्रुप बनाने और उन्हें मैप करने के लिए करें.
ग्रुप बनाने और सदस्यताएं मैनेज करने के लिए, Cloud Identity Groups API का इस्तेमाल करें. ग्रुप को आइडेंटिटी सोर्स से जोड़ने के लिए, आइडेंटिटी सोर्स के नाम को नेमस्पेस के तौर पर इस्तेमाल करें.
इस स्निपेट से एक ग्रुप बनाया जाता है:
ग्रुप एसीएल बनाना
बाहरी आईडी वाला ग्रुप प्रिंसिपल बनाने के लिए, getGroupPrincipal() का इस्तेमाल करें. इसके बाद, एसीएल बनाएं:
आइडेंटिटी कनेक्टर
जब तक उपयोगकर्ताओं के बाहरी आईडी, Cloud Directory में मौजूद Google आईडी से नहीं जुड़ जाते, तब तक वे खोज के नतीजों में आइटम नहीं देख सकते. यह पक्का करने के लिए, तीन तरीके अपनाए जा सकते हैं:
- Admin console में जाकर, उपयोगकर्ता प्रोफ़ाइलों को मैन्युअल तरीके से अपडेट करें (सिर्फ़ टेस्टिंग के लिए सुझाव दिया जाता है).
- Directory API का इस्तेमाल करके मैप आईडी.
- Identity Connector SDK का इस्तेमाल करके, पहचान कनेक्टर बनाएं.
आइडेंटिटी कनेक्टर, एंटरप्राइज़ आइडेंटिटी के बाहरी आईडी को Google की इंटरनल आइडेंटिटी से मैप करते हैं. अगर कोई आइडेंटिटी सोर्स बनाया जाता है, तो आपको आइडेंटिटी कनेक्टर भी बनाना होगा.
Google Cloud डायरेक्ट्री सिंक (GCDS), आइडेंटिटी कनेक्टर का एक उदाहरण है. यह Active Directory से Cloud Directory में उपयोगकर्ता और ग्रुप की जानकारी मैप करता है.
REST API का इस्तेमाल करके आइडेंटिटी सिंक करना
पहचानों को सिंक करने के लिए, update तरीके का इस्तेमाल करें.
आइडेंटिटी रीमैप करना
किसी पहचान को फिर से मैप करने के बाद, आपको आइटम को फिर से इंडेक्स करना होगा, ताकि बदलाव लागू हो सके.
- उपयोगकर्ता की मैपिंग हटाने या बदलने पर, रीइंडेक्सिंग तक ओरिजनल मैपिंग बनी रहती है.
- अगर आपने मैप किए गए किसी ग्रुप को मिटा दिया है और उसी
groupKeyके साथ एक नया ग्रुप बनाया है, तो आपको फिर से इंडेक्स करना होगा. इसके बाद ही, आपको ऐक्सेस मिलेगा.