मैप ACL

यह पक्का करने के लिए कि खोज के नतीजों में सिर्फ़ वे उपयोगकर्ता किसी आइटम को देख पाएं जिनके पास उसका ऐक्सेस है, आपको एंटरप्राइज़ रिपॉज़िटरी से आइटम को उनकी ऐक्सेस कंट्रोल लिस्ट (एसीएल) के साथ इंडेक्स करना चाहिए. आपको अपनी रिपॉज़िटरी के लिए, ऐक्सेस कंट्रोल लिस्ट (एसीएल) बनानी होंगी. साथ ही, रिपॉज़िटरी में मौजूद आइटम को इंडेक्स करते समय, उन एसीएल को शामिल करना होगा. Content Connector SDK, एसीएल के कई तरीके उपलब्ध कराता है. ये तरीके, ज़्यादातर रिपॉज़िटरी के एसीएल को मॉडल करने के लिए काफ़ी असरदार होते हैं.

ध्यान दें: Content Connector SDK टूल, एक डोमेन के लिए एसीएल (ऐक्सेस कंट्रोल लिस्ट) का इस्तेमाल करने की सुविधा देता है. हालांकि, यह अलग-अलग डोमेन के लिए एसीएल का इस्तेमाल करने की सुविधा नहीं देता. अपने संगठन से बाहर के किसी भी उपयोगकर्ता और ग्रुप को ऐक्सेस नहीं दिया जा सकता. आपकी कंपनी से बाहर के उपयोगकर्ताओं या ग्रुप से जुड़े किसी भी एसीएल का कोई असर नहीं होता.

एसीएल बनाना

एसीएल बनाने की प्रोसेस दो चरणों में होती है:

1. ACL क्लास में स्टैटिक तरीकों का इस्तेमाल करके, Principal बनाएं.
2. प्रिंसिपल का इस्तेमाल करके, एसीएल बनाने के लिए Acl.Builder क्लास का इस्तेमाल करें.

इस दस्तावेज़ में आगे, कुछ ऐसे कॉन्सेप्ट के बारे में बताया गया है जिनके बारे में आपको एएलसी बनाने और उन्हें मॉडल करने के लिए जानना ज़रूरी है. जैसे, इनहेरिटेंस और कंटेनमेंट.

बाहरी आईडी का इस्तेमाल करके प्रिंसिपल बनाना

Google Cloud Search के लिए, उपयोगकर्ताओं और ग्रुप को Google ईमेल पते पर रीडायरेक्ट करना ज़रूरी है. रिपॉज़िटरी आइटम को इंडेक्स करते समय, कॉन्टेंट कनेक्टर के पास ये ईमेल पते नहीं हो सकते. हालांकि, Content Connector SDK की मदद से, किसी आइटम को इंडेक्स करने के लिए ईमेल पते के बजाय, किसी भी बाहरी आईडी (ऐसा आईडी जो किसी उपयोगकर्ता या ग्रुप को रिपॉज़िटरी आइटम ऐक्सेस करने की अनुमति देता है) का इस्तेमाल किया जा सकता है. बाहरी आईडी वाले प्रिंसिपल बनाने के लिए, getUserPrincipal() या getGroupPrincpal() तरीके का इस्तेमाल करें. Principal ऑब्जेक्ट बनाने के लिए, ACL क्लास में कई अन्य स्टैटिक तरीके इस्तेमाल किए जाते हैं.

ध्यान दें: उपयोगकर्ताओं को खोज के नतीजों में तब तक आइटम नहीं दिखते, जब तक उनका बाहरी आईडी उनके Google खाते के साथ सिंक नहीं हो जाता. इन बाहरी उपयोगकर्ता या ग्रुप आईडी को Google ईमेल पते के साथ सिंक करने के लिए, आइडेंटिटी कनेक्टर का इस्तेमाल किया जा सकता है. आइडेंटिटी कनेक्टर के बारे में ज़्यादा जानने के लिए, आइडेंटिटी कनेक्टर बनाना लेख पढ़ें.

चेतावनी: किसी आइटम की आइडेंटिटी को दूसरी आइडेंटिटी पर रीमैप करने के बाद, आपको आइटम को फिर से इंडेक्स करना होगा, ताकि नई आइडेंटिटी लागू हो सके. ज़्यादा जानकारी के लिए, पहचान फिर से मैप करना लेख पढ़ें.

एसीएल इनहेरिटेंस

एसीएल इनहेरिटेंस का मतलब है कि किसी आइटम और किसी उपयोगकर्ता के लिए, अनुमति देना. यह अनुमति, आइटम के एसीएल और उसकी इनहेरिटेंस चेन के एसीएल के कॉम्बिनेशन के नतीजे पर आधारित होती है. अनुमति देने या न देने का फ़ैसला करने के लिए इस्तेमाल किए जाने वाले नियम, रिपॉज़िटरी और आइटम की प्रॉपर्टी पर निर्भर करते हैं.

इनहेरिटेंस सेट करना

हर आइटम के लिए, सीधे तौर पर अनुमति दिए गए प्रिंसिपल और सीधे तौर पर अनुमति नहीं दिए गए प्रिंसिपल हो सकते हैं. इन्हें setReaders() और setDeniedReaders() तरीकों का इस्तेमाल करके तय किया जाता है. सीधे तौर पर अनुमति दिया गया प्रिंसिपल, एसीएल में पहचाना गया ऐसा उपयोगकर्ता होता है जिसे किसी आइटम को सीधे तौर पर ऐक्सेस करने की अनुमति होती है. जिस उपयोगकर्ता को किसी आइटम का ऐक्सेस नहीं दिया गया है उसे एसीएल में 'सीधे तौर पर अनुमति नहीं दी गई' के तौर पर मार्क किया जाता है.

setInheritFrom() तरीके का इस्तेमाल करके, किसी आइटम को अन्य ऐप्लिकेशन से मिली अनुमतियां और अन्य ऐप्लिकेशन से मिली अनुमतियां नहीं भी मिल सकती हैं. एसीएल इनहेरिटेंस के ज़रिए, किसी आइटम का ऐक्सेस पाने वाले उपयोगकर्ता को इनडायरेक्ट ऐक्सेस वाला प्रिंसिपल कहा जाता है. जिस उपयोगकर्ता को एसीएल इनहेरिटेंस के ज़रिए किसी आइटम का ऐक्सेस नहीं दिया जाता उसे इनडायरेक्ट डिनाइड प्रिंसिपल कहते हैं.

ध्यान दें: अगर आपने setInheritFrom() तरीके का इस्तेमाल करके इनहेरिटेंस सेट किया है, तो आपको setInheritanceType() तरीके का इस्तेमाल करके इनहेरिटेंस का टाइप सेट करना होगा. इनहेरिटेंस के टाइप के बारे में जानकारी पाने के लिए, इनहेरिटेंस का टाइप सेट करना लेख पढ़ें.

पहली इमेज में दिखाया गया है कि setInheritFrom() तरीके का इस्तेमाल, अन्य ऐप्लिकेशन से मिली अनुमतियों और अन्य ऐप्लिकेशन से मिली अनुमतियों को अस्वीकार करने वाले प्रिंसिपल को इनहेरिट करने के लिए कैसे किया जाता है.

पहली इमेज. setInheritFrom() तरीका.

ऐक्सेस कंट्रोल को पहले डायग्राम में दिखाया गया है:

• उपयोगकर्ता 1, आइटम A का सीधे तौर पर अनुमति दिया गया प्रिंसिपल है.
• उपयोगकर्ता 2, आइटम B का सीधे तौर पर अनुमति दिया गया प्रिंसिपल है.
• आइटम B को आइटम A की ACL मिलती है.

ऐक्सेस कंट्रोल के आधार पर, ऐक्सेस के नियम ये हैं:

• उपयोगकर्ता 1 को आइटम B के मुख्य उपयोगकर्ता के तौर पर साफ़ तौर पर तय करने की ज़रूरत नहीं है, ताकि वह आइटम B का मुख्य उपयोगकर्ता बन सके. ऐक्सेस इसलिए इनहेरिट किया जाता है, क्योंकि उपयोगकर्ता 1 को आइटम A के मुख्य उपयोगकर्ता के तौर पर लिस्ट किया गया है और आइटम B, आइटम A से अपनी एसीएल इनहेरिट करता है.
• उपयोगकर्ता 2, आइटम A के लिए, अनुमति पा चुके प्रिंसिपल के तौर पर शामिल नहीं है.

इनहेरिटेंस का टाइप सेट करना

अगर आपने setInheritFrom() तरीके का इस्तेमाल करके इनहेरिटेंस सेट किया है, तो आपको setInheritanceType() तरीके का इस्तेमाल करके इनहेरिटेंस का टाइप सेट करना होगा. इनहेरिटेंस टाइप से यह तय होता है कि बच्चे के ACL को उसके माता-पिता के ACL के साथ कैसे जोड़ा जाए. Acl.InheritanceType तीन तरह के इनहेरिटेंस लागू करता है:

• BOTH_PERMIT - इनहेरिटेंस टाइप को BOTH_PERMIT पर सेट करें, ताकि किसी उपयोगकर्ता को आइटम का ऐक्सेस सिर्फ़ तब मिले, जब बच्चे के आइटम की एसीएल और पैरंट के इनहेरिट किए गए आइटम की एसीएल, दोनों ही उस उपयोगकर्ता को आइटम ऐक्सेस करने की अनुमति दें.

• CHILD_OVERRIDE - इनहेरिटेंस टाइप को CHILD_OVERRIDE पर सेट करें, ताकि चाइल्ड आइटम की एएलसी, इनहेरिट किए गए पैरंट आइटम की एएलसी पर तब लागू हो, जब दोनों में टकराव हो. इसलिए, अगर पैरंट आइटम की एसीएल में उपयोगकर्ता को रीडर के तौर पर ऐक्सेस नहीं दिया गया है, तो भी उसके पास ऐक्सेस रहेगा. ऐसा तब होगा, जब उसके पास रीडर के तौर पर चाइल्ड आइटम का ऐक्सेस होगा. इसके उलट, अगर पैरंट आइटम की एसीएल से उपयोगकर्ता को ऐक्सेस मिलता है, तब भी उपयोगकर्ता के पास ऐक्सेस नहीं होगा. ऐसा तब होगा, जब उसे चाइल्ड आइटम के लिए रीडर के तौर पर अनुमति नहीं मिली हो.

• PARENT_OVERRIDE - इनहेरिटेंस टाइप को PARENT_OVERRIDE पर सेट करें, ताकि पैरंट आइटम की एसीएल, चाइल्ड आइटम की एसीएल पर तब लागू हो, जब दोनों में टकराव हो. इसलिए, अगर चाइल्ड आइटम की एसीएल, उपयोगकर्ता को रीडर के तौर पर ऐक्सेस करने की अनुमति नहीं देती है, तो भी उपयोगकर्ता के पास ऐक्सेस रहेगा. ऐसा तब होगा, जब उसके पास पैरंट आइटम को रीडर के तौर पर ऐक्सेस करने की अनुमति होगी. इसके उलट, अगर चाइल्ड आइटम की एसीएल, उपयोगकर्ता को ऐक्सेस देती है, लेकिन पैरंट आइटम के लिए उपयोगकर्ता को रीडर की भूमिका नहीं दी गई है, तो उसके पास ऐक्सेस नहीं होगा.

एसीएल इनहेरिटेंस चेन का आकलन करते समय, आकलन का क्रम बदल सकता है. इससे अनुमति देने या न देने के फ़ैसले पर असर पड़ सकता है. Cloud Search, एसीएल इनहेरिटेंस चेन के लिए, लीफ़-टू-रूट क्रम में आकलन करता है. खास तौर पर, किसी चेन के लिए ACL का फ़ैसला, माता-पिता के साथ बच्चे के आकलन से शुरू होता है. यह फ़ैसला, माता-पिता के मुख्य खाते तक पहुंच सकता है.

उदाहरण के लिए, अगर बच्चे के पास CHILD_OVERRIDE इनहेरिटेंस टाइप है और उपयोगकर्ता के पास बच्चे का ऐक्सेस है, तो Drive को पैरंट का आकलन करने की ज़रूरत नहीं है. हालांकि, अगर बच्चे के पास PARENT_OVERRIDE या BOTH_PERMIT है, तो Drive, चेन में आगे की ओर इनहेरिटेंस का आकलन करना जारी रखता है.

आइटम को सीमित करना और मिटाना

किसी आइटम को इंडेक्स करते समय, IndexingItemBuilder क्लास के setContainer() तरीके का इस्तेमाल करके, किसी आइटम को कंटेनर के तौर पर लेबल किया जा सकता है. कंटेनर/कंटेनी के बीच संबंध, आइटम की फ़िज़िकल हैरारकी तय करता है. साथ ही, यह पक्का करता है कि आइटम सही तरीके से मिटाए गए हों. किसी कंटेनर को मिटाने पर, उसमें मौजूद आइटम भी मिट जाते हैं.

कंटेनमेंट के संबंध, ACL इनहेरिटेंस के नियमों से पूरी तरह अलग होते हैं. उदाहरण के लिए, फ़ाइल सिस्टम में मौजूद किसी फ़ाइल को मिटाने के लिए, उसे किसी फ़ोल्डर में रखा जा सकता है. हालांकि, वह किसी दूसरे फ़ोल्डर से एसीएल इनहेरिट करती है. किसी फ़ोल्डर को मिटाने से, उन आइटम को नहीं मिटाया जाता है जो उसके एएलसी को इनहेरिट करते हैं. हालांकि, ऐसा तब होता है, जब वे आइटम फ़ोल्डर की कंटेनमेंट हैरारकी में भी मौजूद हों.

ऐक्सेस कंट्रोल को दूसरे डायग्राम में दिखाया गया है:

• उपयोगकर्ता 1, आइटम A का सीधे तौर पर अनुमति दिया गया प्रिंसिपल है.
• उपयोगकर्ता 2, आइटम B का सीधे तौर पर अनुमति दिया गया प्रिंसिपल है.
• उपयोगकर्ता 3 को आइटम C को सीधे तौर पर ऐक्सेस करने की अनुमति है.
• आइटम C को आइटम A के ACL मिलते हैं.
• आइटम B, आइटम A को अपने कंटेनर के तौर पर दिखाता है.
• आइटम C, आइटम B को अपने कंटेनर के तौर पर दिखाता है.

ऐक्सेस कंट्रोल के आधार पर, ऐक्सेस के नियम ये हैं:

• अप्रत्यक्ष ऐक्सेस, setInheritFrom() तरीके से मिलता है. इसलिए, उपयोगकर्ता 1, आइटम C को ऐक्सेस कर सकता है, क्योंकि आइटम C को आइटम A की एसीएल इनहेरिट की गई है.
• इनडायरेक्ट ऐक्सेस, आइटम C को आइटम B में शामिल करने से नहीं मिलता. इसलिए, उपयोगकर्ता 2, आइटम C को ऐक्सेस नहीं कर सकता.

दूसरी इमेज. setInheritFrom() वाला तरीका इस्तेमाल किया जा रहा है.

एसीएल इनहेरिटेंस को कंटेनमेंट हैरारकी से अलग करने पर, कई अलग-अलग मौजूदा स्ट्रक्चर को मॉडल किया जा सकता है.

किसी आइटम को मिटाने पर:

• जिस आइटम में मिटाया गया आइटम मौजूद होता है उसे खोजा नहीं जा सकता. साथ ही, उसे Google के डेटा सोर्स से मिटाने के लिए शेड्यूल कर दिया जाता है.
• setInheritFrom() तरीके का इस्तेमाल करके, मिटाए गए आइटम के बारे में जानकारी देने वाला कोई भी आइटम खोजा नहीं जा सकता.

अगर किसी संसाधन में setInheritFrom() तरीके का इस्तेमाल करके कोई आइटम मिटाया गया है, लेकिन उसमें setContainer() का इस्तेमाल करके कोई कंटेनर सेट नहीं किया गया है या उसकी कंटेनमेंट हैरारकी में कोई मिटाया गया आइटम नहीं है, तो वह आइटम और उसका डेटा Google के डेटा सोर्स में बना रहता है. आइटम को मिटाने की ज़िम्मेदारी आपकी है.

तीसरी इमेज में, आइटम के क्रम के हिसाब से डेटा मिटाने का उदाहरण दिखाया गया है.

तीसरी इमेज. किसी आइटम को मिटाना और एएलसी इनहेरिटेंस.

ऐक्सेस कंट्रोल को तीसरे डायग्राम में दिखाया गया है:

• उपयोगकर्ता 1, आइटम A का सीधे तौर पर अनुमति दिया गया प्रिंसिपल है.
• उपयोगकर्ता 2, आइटम D का सीधे तौर पर अनुमति दिया गया प्रिंसिपल है.
• आइटम D और आइटम E, दोनों को आइटम A की एसीएल सेटिंग इनहेरिट की गई हैं.
• आइटम D, आइटम A को अपने कंटेनर के तौर पर दिखाता है.
• आइटम A और E, रूट लेवल के आइटम हैं, क्योंकि इनमें कंटेनर आइटम नहीं है.

मिटाए गए कंटेनर के रेफ़रंस भी मिट जाते हैं. आइटम A को मिटाने पर:

• setInheritFrom() रेफ़रंस के सभी डिसेंडेंट के लिए, सभी उपयोगकर्ताओं का ऐक्सेस हट जाता है.
• कोई भी उपयोगकर्ता, आइटम A को ऐक्सेस नहीं कर सकता.
• आइटम D को अपने-आप मिटा दिया जाता है. कोई भी उपयोगकर्ता आइटम D को ऐक्सेस नहीं कर सकता.
• आइटम E नहीं मिटाया गया है, क्योंकि मिटाने की कार्रवाई सिर्फ़ कंटेनर के रेफ़रंस पर लागू होती है.
• आइटम E को ऐक्सेस नहीं किया जा सकता. साथ ही, कोई भी उपयोगकर्ता आइटम E को खोज नहीं सकता.