Google Cloud Search में ऐक्सेस कंट्रोल, उपयोगकर्ता के Google खाते पर आधारित होता है. कॉन्टेंट को इंडेक्स करते समय, आइटम पर मौजूद सभी एसीएल (ACL) Google के मान्य उपयोगकर्ता या ग्रुप आईडी (ईमेल पते) से रिज़ॉल्व होने चाहिए.
कई मामलों में, डेटा स्टोर करने की जगह के पास Google खातों के बारे में सीधे तौर पर जानकारी नहीं होती. इसके बजाय, हर खाते की पहचान करने के लिए, उपयोगकर्ता स्थानीय खातों से दिखाए जा सकते हैं या उपयोगकर्ता के ईमेल पते के अलावा, किसी आइडेंटिटी प्रोवाइडर और आईडी के साथ फ़ेडरेटेड साइन-इन का इस्तेमाल किया जा सकता है. इस आईडी को बाहरी आईडी कहा जाता है.
Admin console का इस्तेमाल करके बनाए गए, पहचान के सोर्स से, अलग-अलग पहचान करने के सिस्टम के बीच के अंतर को कम करने में मदद मिलती है. ये तरीके हैं:
- बाहरी आईडी सेव करने के लिए कस्टम उपयोगकर्ता फ़ील्ड तय करना. इस फ़ील्ड का इस्तेमाल, किसी Google खाते में बाहरी आईडी डालने के लिए किया जाता है.
- सुरक्षा ग्रुप के लिए नेमस्पेस तय करें, जिसे डेटा स्टोर करने की जगह या आइडेंटिटी प्रोवाइडर से मैनेज किया जाता है.
पहचान स्रोतों का इस्तेमाल तब करें, जब:
- डेटा स्टोर करने की जगह के पास, Google Workspace या Google Cloud डायरेक्ट्री में मौजूद उपयोगकर्ता के मुख्य ईमेल पते की जानकारी नहीं होती.
- रिपॉज़िटरी, ऐक्सेस कंट्रोल के लिए ऐसे ग्रुप तय करता है जो Google Workspace में ईमेल-आधारित ग्रुप से मेल नहीं खाते.
आइडेंटिटी सोर्स, इंडेक्स करने की सुविधा को आइडेंटिटी मैपिंग से अलग करके इंडेक्स करने की सुविधा को बेहतर बनाते हैं. इस डिकोडिंग से, एसीएल बनाते और आइटम इंडेक्स करते समय, उपयोगकर्ता को दिखने से रोकने में मदद मिलती है.
डिप्लॉयमेंट का उदाहरण
इमेज 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 |
हर उस बाहरी आईडी के लिए एक पहचान स्रोत बनाएं जिसका इस्तेमाल आपके एंटरप्राइज़ में किसी उपयोगकर्ता के लिए किया जाता है.
इस टेबल में दिखाया गया है कि Cloud डायरेक्ट्री में उपयोगकर्ता के पास 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
पैटर्न का इस्तेमाल किया जाता है. पिछली टेबल देखें, तो
अगर आपने एन के id1_identity
(SAMAccountName) के साथ ACL बनाया है, तो आईडी का समाधान हो जाएगा:
identitysources/id1_identity/users/example/ann
इस पूरे आईडी को उपयोगकर्ता का इंटरमीडिएट आईडी कहा जाता है क्योंकि यह बाहरी आईडी और क्लाउड डायरेक्ट्री में स्टोर किए गए Google आईडी के बीच एक पुल का काम करता है.
डेटा स्टोर करने की जगह के लिए इस्तेमाल किए गए ACL की मॉडलिंग के बारे में ज़्यादा जानकारी के लिए, ACL देखें.
ग्रुप मैप करें
पहचान स्रोत ACL में इस्तेमाल किए गए समूहों के लिए नेमस्पेस के रूप में भी काम करते हैं. इस नेमस्पेस सुविधा का इस्तेमाल करके, ऐसे ग्रुप बनाए जा सकते हैं और मैप किए जा सकते हैं जिनका इस्तेमाल सिर्फ़ सुरक्षा के लिए किया जाता है या जो डेटा स्टोर करने की जगह के लिए लोकल तौर पर उपलब्ध होते हैं.
ग्रुप बनाने और सदस्यताओं को मैनेज करने के लिए, Cloud Identity Groups API का इस्तेमाल करें. ग्रुप को किसी पहचान सोर्स से असोसिएट करने के लिए, ग्रुप नेमस्पेस के तौर पर पहचान सोर्स के रिसॉर्स का नाम इस्तेमाल करें.
यह कोड स्निपेट, Cloud Identity Groups API का इस्तेमाल करके ग्रुप बनाने का तरीका बताता है:
समूह ACL बनाएं
ग्रुप एसीएल बनाने के लिए, दिए गए बाहरी आईडी का इस्तेमाल करके getGroupPrincipal() तरीके का इस्तेमाल करके ग्रुप प्रिंसिपल बनाएं. इसके बाद, इस तरह Acl.Builder क्लास का इस्तेमाल करके, एसीएल बनाएं:
आइडेंटिटी कनेक्टर
एसीएल और इंडेक्स आइटम बनाने के लिए, Google से बाहर के और बाहरी आईडी का इस्तेमाल किया जा सकता है. हालांकि, उपयोगकर्ता तब तक खोज में आइटम नहीं देख सकते, जब तक कि उनके बाहरी आईडी, क्लाउड डायरेक्ट्री में Google आईडी में नहीं बदल जाते. किसी उपयोगकर्ता के Google आईडी और बाहरी आईडी, दोनों की जानकारी Cloud डायरेक्ट्री को देने के तीन तरीके हैं:
- Admin console की मदद से, हर उपयोगकर्ता की प्रोफ़ाइल को मैन्युअल तरीके से अपडेट करें इस प्रोसेस का सुझाव, सिर्फ़ कुछ उपयोगकर्ताओं की प्रोफ़ाइलों का इस्तेमाल करके टेस्टिंग और प्रोटोटाइप करने के लिए दिया जाता है.
- डायरेक्ट्री एपीआई का इस्तेमाल करके, Google आईडी पर बाहरी आईडी मैप करें. इस प्रोसेस का सुझाव उन लोगों को दिया जाता है जो Identity Connector SDK टूल का इस्तेमाल नहीं कर सकते.
- Identity Connector SDK टूल का इस्तेमाल करके, पहचान कनेक्टर बनाएं. यह SDK टूल, आईडी को मैप करने के लिए, डायरेक्ट्री एपीआई के इस्तेमाल को आसान बनाता है.
आइडेंटिटी कनेक्टर ऐसे प्रोग्राम होते हैं जिनका इस्तेमाल एंटरप्राइज़ पहचानों (उपयोगकर्ता और ग्रुप) से बाहरी आईडी को Google Cloud Search में इस्तेमाल की जाने वाली अंदरूनी Google पहचान से मैप करने के लिए किया जाता है. अगर आपको आइडेंटिटी सोर्स बनाना है, तो आपको आइडेंटिटी कनेक्टर बनाना होगा.
Google Cloud डायरेक्ट्री सिंक (जीसीडीएस), आइडेंटिटी कनेक्टर का एक उदाहरण है. यह आइडेंटिटी कनेक्टर, उपयोगकर्ता और ग्रुप की जानकारी को Microsoft की Active Directory से क्लाउड डायरेक्ट्री में मैप करता है. साथ ही, उपयोगकर्ता एट्रिब्यूट के साथ-साथ उन एट्रिब्यूट को भी मैप करता है जो अन्य सिस्टम में उनकी पहचान को दिखा सकते हैं.
REST API का इस्तेमाल करके, पहचानों को सिंक करें
REST API का इस्तेमाल करके, पहचानों को सिंक करने के लिए, update
तरीके का इस्तेमाल करें.
आइडेंटिटी रीमैप करना
किसी आइटम की पहचान को दूसरी पहचान के साथ फिर से मैप करने के बाद, नई पहचान को होल्ड पर रखने के लिए आपको आइटम को फिर से इंडेक्स करना होगा. उदाहरण के लिए,
- अगर किसी उपयोगकर्ता से मैपिंग को हटाने या उसे किसी दूसरे उपयोगकर्ता के लिए रीमैप करने की कोशिश की जाती है, तो ओरिजनल मैपिंग को तब तक सुरक्षित रखा जाता है, जब तक कि उसे फिर से इंडेक्स नहीं किया जाता.
- अगर मैप किए गए किसी ऐसे ग्रुप को मिटाया जाता है जो आइटम ACL में मौजूद है और फिर उसी
groupKey
के साथ एक नया ग्रुप बनाया जाता है, तो नया ग्रुप आइटम को तब तक ऐक्सेस नहीं करता, जब तक आइटम को फिर से इंडेक्स नहीं किया जाता.