paint-brush
लॉगिन से परे: ZITADEL के साथ बढ़िया प्राधिकरण लागू करेंद्वारा@zitadel
3,959 रीडिंग
3,959 रीडिंग

लॉगिन से परे: ZITADEL के साथ बढ़िया प्राधिकरण लागू करें

द्वारा ZITADEL20m2023/11/10
Read on Terminal Reader

बहुत लंबा; पढ़ने के लिए

यह आलेख पारंपरिक भूमिका-आधारित अभिगम नियंत्रण से सुव्यवस्थित सुरक्षा तक के परिवर्तन पर प्रकाश डालता है। ZITADEL गतिशील सुविधाओं के साथ प्राधिकरण को बढ़ाता है और अनुरूप आवश्यकताओं के लिए बाहरी एकीकरण का समर्थन करता है। एक व्यावहारिक उदाहरण इन सिद्धांतों को क्रियान्वित करता है। व्यावहारिक डेवलपर्स के लिए, लेख में पायथन में पूर्ण कोड कार्यान्वयन शामिल है।
featured image - लॉगिन से परे: ZITADEL के साथ बढ़िया प्राधिकरण लागू करें
ZITADEL HackerNoon profile picture
0-item
1-item


परिचय

जैसे-जैसे हम शून्य-विश्वास मानसिकता की ओर बढ़ते हैं, पारंपरिक आरबीएसी प्रणाली जैसे मोटे सुरक्षा उपायों की सीमा स्पष्ट हो जाती है। शून्य विश्वास में बदलाव का एक अनिवार्य हिस्सा जिस पर अक्सर चर्चा नहीं की जाती है, वह है मोटे-मोटे सुरक्षा से बारीक-बारीक सुरक्षा की ओर बढ़ना।


सूक्ष्म प्राधिकरण इसे उपयोगकर्ता की भूमिकाओं, कार्यों और यहां तक कि समय या स्थान जैसे संदर्भ जैसी विशेषताओं पर पहुंच के आधार पर संबोधित करता है, और इस तरह का विस्तृत पहुंच नियंत्रण आधुनिक अनुप्रयोगों के लिए महत्वपूर्ण है। यह आलेख चर्चा करता है कि कैसे ज़िटाडेल ऐसे सूक्ष्म प्राधिकरण की आवश्यकता को पूरा करता है।


ZITADEL की भूमिकाओं, मेटा-डेटा और कार्यों जैसी सुविधाओं के साथ, उपयोगकर्ता शून्य-विश्वास सेटिंग के लिए उपयुक्त अत्यधिक विस्तृत पहुंच नियंत्रण प्राप्त कर सकते हैं। इसके अतिरिक्त, ZITADEL बाहरी प्राधिकरण सेवाओं के साथ काम कर सकता है।

ZITADEL द्वारा प्रस्तुत प्राधिकरण तंत्र

ज़िटाडेल एक है खुला स्त्रोत , क्लाउड-नेटिव आइडेंटिटी एंड एक्सेस मैनेजमेंट सॉल्यूशन (IAM) गो में लिखा गया है। ZITADEL एक SaaS समाधान के रूप में उपलब्ध है, और यह लचीलेपन को सुनिश्चित करते हुए स्व-होस्टिंग विकल्प चाहने वालों के लिए खुला स्रोत भी है। यह B2C और B2B दोनों उपयोग के मामलों को पूरा करता है।


इसके प्राथमिक उद्देश्यों में यूजर इंटरफेस के माध्यम से अनुकूलन की अनुमति देते हुए प्रमाणीकरण, प्राधिकरण, लॉगिन और सिंगल साइन-ऑन (एसएसओ) के लिए टर्नकी सुविधाएं प्रदान करना शामिल है।


यह सभी परिवर्तनों पर नज़र रखने के लिए एक व्यापक ऑडिट ट्रेल के साथ आता है, डेवलपर्स को कस्टम कोड (क्रियाओं) के साथ कार्यक्षमताओं का विस्तार करने में सक्षम बनाता है, ओआईडीसी, ओएथ, एसएएमएल और एलडीएपी जैसे व्यापक रूप से मान्यता प्राप्त मानकों का समर्थन करता है, संचालन और स्केलेबिलिटी में आसानी पर जोर देता है, और इसके लिए व्यापक एपीआई प्रदान करता है। बहुमुखी एकीकरण.

भूमिका-आधारित पहुंच नियंत्रण (आरबीएसी) और प्रत्यायोजित पहुंच

ZITADEL उपयोगकर्ता अनुमतियों को प्रबंधित करने के लिए RBAC का उपयोग करता है, जहां अनुमतियाँ भूमिकाओं से जुड़ी होती हैं, और उपयोगकर्ताओं को ये भूमिकाएँ आवंटित की जाती हैं। यह उनकी संगठनात्मक भूमिकाओं के आधार पर उपयोगकर्ता पहुंच प्रबंधन को सरल बनाता है। एक अतिरिक्त सुविधा अन्य संगठनों को भूमिकाएँ सौंपने की अनुमति देती है, जिससे बाहरी संस्थाओं के साथ अनुमतियाँ साझा करने में सुविधा होती है।


यह परस्पर जुड़े या पदानुक्रमित संगठनों के लिए विशेष रूप से मूल्यवान है।


हालांकि ये क्षमताएं मजबूत पहुंच नियंत्रण प्रदान करती हैं, लेकिन वे जटिल प्राधिकरण आवश्यकताओं के लिए पर्याप्त नहीं हो सकती हैं, इसलिए ZITADEL में सूक्ष्म प्राधिकरण की खोज का महत्व है।

क्रियाएँ फ़ीचर, कस्टम मेटाडेटा, और विशेषता-आधारित एक्सेस कंट्रोल (एबीएसी) के लिए दावे

ZITADEL अपनी गतिशीलता का परिचय देकर पारंपरिक RBAC को बढ़ाता है कार्रवाई विशेषता-आधारित अभिगम नियंत्रण (एबीएसी) के लिए सुविधा। आरबीएसी के विपरीत, जो उपयोगकर्ता भूमिकाओं के आधार पर पहुंच प्रदान करता है, एबीएसी अधिक बहुमुखी है, पहुंच अनुरोधों के दौरान उपयोगकर्ता, कार्रवाई और संसाधन से जुड़ी विशेषताओं का आकलन करता है।


ZITADEL के कार्यों के साथ, विशिष्ट उपयोगकर्ता विशेषताओं का विश्लेषण करने और आवश्यक होने पर पहुंच को अवरुद्ध करने के लिए पोस्ट-प्रमाणीकरण स्क्रिप्ट बनाई जा सकती हैं।


कार्रवाइयां एबीएसी प्रणाली को बढ़ावा देने के लिए कस्टम दावे भी स्थापित कर सकती हैं, जिससे उन्नत प्राधिकरण मॉडल सक्षम हो सकते हैं जो स्थान, समय या किसी निश्चित कारक जैसी विशेषताओं के आधार पर पहुंच को प्रतिबंधित करते हैं।


ZITADEL प्रशासकों या अनुमति प्राप्त डेवलपर्स को उपयोगकर्ताओं और संगठनों में कस्टम मेटाडेटा जोड़ने की सुविधा देता है, जिससे सूक्ष्म पहुंच नियंत्रण संभावनाएं बढ़ जाती हैं।


यह सीआरएम या एचआर टूल जैसे बाहरी सिस्टम से अतिरिक्त डेटा एकत्र करके समग्र दावों का समर्थन करता है। ZITADEL अद्वितीय संसाधनों का प्रबंधन भी कर सकता है, जैसे शिपिंग ऑर्डर या IoT डिवाइस, और उपयोगकर्ता-उप, भूमिकाएं, दावे, आईपी और अधिक जैसी विशेषताओं के आधार पर पहुंच निर्धारित कर सकता है।

फाइन-ग्रेन्ड एक्सेस कंट्रोल के लिए ZITADEL की मौजूदा क्षमताओं का विस्तार

ZITADEL के साथ आने वाली व्यापक सुविधाओं के बावजूद, ऐसे उदाहरण हो सकते हैं जहां अधिक अनुकूलित या सुक्ष्म दृष्टिकोण की आवश्यकता होती है।


वर्तमान में, ZITADEL में बारीक प्राधिकरण को लागू करने का सबसे प्रभावी तरीका छोटी परियोजनाओं के लिए या बड़े पैमाने की परियोजनाओं के लिए कस्टम एप्लिकेशन लॉजिक का उपयोग करना है, जो उपलब्ध तृतीय-पक्ष टूल जैसे कि वारंट.देव , सेर्बोस.देव , आदि का लाभ उठाता है।


ये उपकरण ZITADEL के साथ एकीकृत हो सकते हैं, जो सूक्ष्म, सूक्ष्म प्राधिकरण के लिए आपकी क्षमता को और बढ़ाएंगे।

एक व्यावहारिक उदाहरण

मान लीजिए कि एक मीडिया कंपनी में एक काल्पनिक न्यूज़रूम एप्लिकेशन है, जो बैक-एंड एपीआई से बात करता है। पत्रकार इसका उपयोग लिखने के लिए करते हैं, जबकि संपादक इन लेखों को संपादित और प्रकाशित करते हैं। इस उदाहरण में पायथन फ्लास्क में लिखे गए इस एपीआई में विशिष्ट समापन बिंदु हैं और इन समापन बिंदुओं तक पहुंच उपयोगकर्ता की भूमिका और वे कितने अनुभवी हैं, इस पर निर्भर करता है। अंतिम बिंदु:


  • write_article : केवल पत्रकारों के लिखने के लिए।


  • edit_article : केवल संपादकों के लिए लेख संपादित करना।


  • review_articles : वरिष्ठ पत्रकारों और मध्यवर्ती और वरिष्ठ संपादकों के लिए लेखों की समीक्षा करना।


  • publish_article : मध्यवर्ती और वरिष्ठ पत्रकारों और वरिष्ठ संपादकों के लिए प्रकाशन हेतु। आंतरिक रूप से, एपीआई यह जांचने के लिए ZITADEL द्वारा जारी JWT का उपयोग करता है कि कौन अनुरोध कर रहा है। उपयोगकर्ताओं को अपने अनुरोध के शीर्षलेख में एक वैध JWT भेजना होगा। यह JWT तब प्राप्त हुआ जब उपयोगकर्ता ने लॉग इन किया।


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

अनुप्रयोग तर्क

आरेख 1: लॉगिन से परे सुक्ष्म प्राधिकरण की सहभागिता



  • उपयोगकर्ता ऑनबोर्डिंग : उपयोगकर्ता ऑनबोर्डिंग प्रक्रिया के दौरान, प्रत्येक उपयोगकर्ता को एक भूमिका मिलती है, उदाहरण के लिए, journalist या editor । यह महत्वपूर्ण है क्योंकि यह निर्धारित करता है कि हमारे सेटअप में किसे कौन सी पहुंच मिलती है। अनुभव/वरिष्ठता का प्रबंधन: भूमिकाओं के अलावा, उपयोगकर्ता के अनुभव (जैसे हमारे उदाहरण में junior , intermediate और senior ) को ट्रैक किया जाता है। यदि किसी उपयोगकर्ता का अनुभव बदलता है, तो ZITADEL इसे मेटाडेटा के रूप में अपडेट करता है। जब कोई उपयोगकर्ता ZITADEL पर चढ़ता है तो यदि कोई अनुभव स्तर का उल्लेख नहीं किया गया है, तो सिस्टम इसे 'जूनियर' मान लेता है।


  • उपयोगकर्ता लॉगिन : एपीआई तक पहुंचने के लिए उपयोगकर्ता को पहले लॉगिन करना होगा। सफल लॉगिन पर, ZITADEL उपयोगकर्ता की जानकारी के साथ एक टोकन लौटाता है।


  • टोकन सत्यापन: जब किसी उपयोगकर्ता का अनुरोध एपीआई पर आता है, तो एपीआई ZITADEL के टोकन आत्मनिरीक्षण समापन बिंदु पर कॉल करके टोकन को मान्य करता है। हालाँकि JWTS को JWKS का उपयोग करके स्थानीय रूप से मान्य किया जा सकता है, हमने बेहतर सुरक्षा और त्वरित टोकन जाँच के लिए टोकन का निरीक्षण करने के लिए ZITADEL की विधि अपनाई। इस तरह, हम टोकन को तुरंत रद्द कर सकते हैं, उन्हें एक ही स्थान से प्रबंधित कर सकते हैं, और सुरक्षा समस्याएं कम हो सकती हैं। यह हमारे एपीआई के लॉगिन और एक्सेस नियंत्रण को सर्वर के साथ मजबूत और अद्यतित रखता है।


  • फाइन-ग्रेन्ड एक्सेस कंट्रोल: एप्लिकेशन उपयोगकर्ता की भूमिका और अनुभव स्तर के आधार पर संसाधनों तक पहुंच को अधिकृत करने के लिए जिम्मेदार है। यह एक पूर्वनिर्धारित एक्सेस नियंत्रण सूची का उपयोग करता है जो प्रत्येक संसाधन समापन बिंदु को उपयोगकर्ता भूमिकाओं और उन तक पहुंचने के लिए अधिकृत अनुभव स्तरों पर मैप करता है। यह सूची संसाधनों तक पहुंच प्रदान करने या अस्वीकार करने के लिए नियम पुस्तिका के रूप में कार्य करती है।


  • चिंताओं को अलग करना : इस एपीआई के डिजाइन में, यह सुनिश्चित करने पर विशेष ध्यान दिया गया था कि व्यावसायिक तर्क और पहुंच नियंत्रण नियम स्पष्ट रूप से अलग हो गए हैं। यह एप्लिकेशन की रखरखाव और स्केलेबिलिटी के लिए महत्वपूर्ण है। व्यावसायिक तर्क और पहुंच नियमों को अलग रखने से, हमें एक स्वच्छ, मॉड्यूलर डिज़ाइन मिलता है।


    इससे हम एक-दूसरे को प्रभावित किए बिना व्यावसायिक गतिविधियों और एक्सेस नियमों को अपडेट कर सकते हैं। इससे कोड की रखरखाव क्षमता बढ़ जाती है और एप्लिकेशन स्केल के रूप में इसे प्रबंधित करना आसान हो जाता है।


    इसके अतिरिक्त, यह डिज़ाइन सिस्टम को अधिक सुरक्षित बनाता है क्योंकि एक्सेस नियमों को मुख्य व्यावसायिक तर्क से दूर कर दिया जाता है, जिससे व्यावसायिक तर्क को संशोधित करते समय गलती से सुरक्षा कमजोरियों का जोखिम कम हो जाता है।

ZITADEL की स्थापना करें

1. मीडिया हाउस संगठन, न्यूज़रूम प्रोजेक्ट और आर्टिकल एपीआई बनाएं

  1. मीडिया हाउस संगठन बनाएं, प्रोजेक्ट्स पर जाएं और न्यूज़रूम नामक एक नया प्रोजेक्ट बनाएं।



  2. न्यूज़रूम प्रोजेक्ट में, नया एप्लिकेशन बनाने के लिए नया बटन पर क्लिक करें।



  1. एक नाम जोड़ें, और एपीआई प्रकार चुनें।



  1. प्रमाणीकरण विधि के रूप में बेसिक का चयन करें और जारी रखें पर क्लिक करें।



  1. अब अपने कॉन्फ़िगरेशन की समीक्षा करें और Create पर क्लिक करें।



  1. अब आपको एपीआई की क्लाइंट आईडी और क्लाइंट सीक्रेट दिखाई देगा। उन्हें कॉपी करें और सेव करें. बंद करें पर क्लिक करें.



  1. जब आप बाईं ओर यूआरएल पर क्लिक करेंगे, तो आपको प्रासंगिक ओआईडीसी यूआरएल दिखाई देंगे। जारीकर्ता यूआरएल, टोकन_एंडपॉइंट और इंट्रोस्पेक्शन_एंडपॉइंट नोट करें।



2. न्यूज़रूम प्रोजेक्ट में भूमिकाएँ बनाएँ

  1. साथ ही, अपने प्रोजेक्ट की रिसोर्स आईडी भी नोट कर लें (प्रोजेक्ट पर जाएं और रिसोर्स आईडी कॉपी करें)



  1. प्रोजेक्ट डैशबोर्ड पर प्रमाणीकरण चेकबॉक्स पर भूमिकाएँ निर्दिष्ट करें का चयन करें और सहेजें पर क्लिक करें।



  1. भूमिकाओं पर जाएँ (बाएँ मेनू से), और नई भूमिकाएँ जोड़ने के लिए नया पर क्लिक करें।



  1. जैसा कि नीचे दिखाया गया है, संपादक और पत्रकार की भूमिकाएँ दर्ज करें और सहेजें पर क्लिक करें।



  1. अब आप बनाई गई भूमिकाएँ देखेंगे।



3. न्यूज़रूम प्रोजेक्ट में उपयोगकर्ता बनाएँ

  1. जैसा कि नीचे दिखाया गया है, अपने संगठन में उपयोगकर्ता टैब पर जाएं और सेवा उपयोगकर्ता टैब पर जाएं। हम इस डेमो में सेवा उपयोगकर्ता बनाएंगे। सेवा उपयोगकर्ता जोड़ने के लिए, नया बटन पर क्लिक करें।


    सेवा उपयोगकर्ता बनाएँ


  2. इसके बाद, सेवा उपयोगकर्ता का विवरण जोड़ें, एक्सेस टोकन प्रकार के लिए JWT चुनें और Create पर क्लिक करें।


    सेवा उपयोगकर्ता बनाएँ


  3. ऊपरी दाएं कोने पर क्रियाएँ बटन पर क्लिक करें। ड्रॉप-डाउन मेनू से जेनरेट क्लाइंट सीक्रेट चुनें।




  4. अपनी क्लाइंट आईडी और क्लाइंट सीक्रेट कॉपी करें। बंद करें पर क्लिक करें.



  5. अब, आपके पास उनके ग्राहक क्रेडेंशियल्स के साथ एक सेवा उपयोगकर्ता है।

4. उपयोगकर्ताओं के लिए प्राधिकरण जोड़ें

  1. प्राधिकरण पर जाएं. नया क्लिक करें.


  2. उपयोगकर्ता और प्रोजेक्ट का चयन करें जिसके लिए प्राधिकरण बनाया जाना चाहिए। जारी रखें पर क्लिक करें.



  3. आप यहां एक भूमिका चुन सकते हैं. वर्तमान उपयोगकर्ता के लिए पत्रकार की भूमिका चुनें। सहेजें पर क्लिक करें.


    प्राधिकरण जोड़ें


  4. आप देख सकते हैं कि सेवा उपयोगकर्ता लोइस लेन की अब न्यूज़रूम परियोजना में पत्रकार की भूमिका है।



5. उपयोगकर्ताओं के लिए मेटाडेटा जोड़ें

अब, आइए उनकी वरिष्ठता के स्तर को इंगित करने के लिए उपयोगकर्ता प्रोफ़ाइल में मेटाडेटा जोड़ें। कुंजी के रूप में 'अनुभव_स्तर' का उपयोग करें, और इसके मूल्य के लिए, 'जूनियर', 'मध्यवर्ती', या 'वरिष्ठ' में से चुनें।


हालाँकि हम आमतौर पर यह मान सकते हैं कि यह मेटाडेटा एचआर एप्लिकेशन द्वारा किए गए एपीआई कॉल के माध्यम से सेट किया गया है, सरलता और समझने में आसानी के लिए, हम मेटाडेटा को सीधे कंसोल में सेट करेंगे।


  1. मेटाडेटा पर जाएँ. संपादित करें पर क्लिक करें.



  2. key के रूप में Experience_level और मान के रूप में Senior प्रदान करें। सेव आइकन पर क्लिक करें और बंद करें बटन पर क्लिक करें।



  3. उपयोगकर्ता के पास अब उनके खाते से संबद्ध आवश्यक मेटाडेटा है।



  4. आप पिछले चरणों का उपयोग करके डेमो का परीक्षण करने के लिए विभिन्न भूमिकाओं और अनुभव_स्तरों (मेटाडेटा का उपयोग करके) के साथ कुछ और सेवा उपयोगकर्ताओं को भी जोड़ सकते हैं।


6. कस्टम दावे में भूमिका और मेटाडेटा कैप्चर करने के लिए एक कार्रवाई बनाएं

1. क्रियाएँ पर क्लिक करें। नई कार्रवाई बनाने के लिए नया पर क्लिक करें।



2. एक क्रिया बनाएं अनुभाग में, क्रिया को फ़ंक्शन नाम के समान नाम दें, यानी, assignRoleAndExperienceClaims। स्क्रिप्ट फ़ील्ड में, निम्नलिखित कोड को कॉपी/पेस्ट करें और फिर जोड़ें पर क्लिक करें।



 function assignRoleAndExperienceClaims(ctx, api) { // Check if grants and metadata exist if (!ctx.v1.user.grants || !ctx.v1.claims['urn:zitadel:iam:user:metadata']) { return; } // Decode experience level from Base64 - metadata is Base64 encoded let experience_encoded = ctx.v1.claims['urn:zitadel:iam:user:metadata'].experience_level; let experience = ''; try { experience = decodeURIComponent(escape(String.fromCharCode.apply(null, experience_encoded.split('').map(function(c) { return '0x' + ('0' + c.charCodeAt(0).toString(16)).slice(-2); })))); } catch (e) { return; // If decoding fails, stop executing the function } // Check if the experience level exists if (!experience) { return; } // Iterate through the user's grants ctx.v1.user.grants.grants.forEach(grant => { // Iterate through the roles of each grant grant.roles.forEach(role => { // Check if the user is a journalist if (role === 'journalist') { // Set custom claims with the user's role and experience level api.v1.claims.setClaim('journalist:experience_level', experience); } // Check if the user is an editor else if (role === 'editor') { // Set custom claims with the user's role and experience level api.v1.claims.setClaim('editor:experience_level', experience); } }); }); }


  1. assignRoleAndExperienceClaims को अब एक क्रिया के रूप में सूचीबद्ध किया जाएगा।



  1. इसके बाद, हमें एक फ़्लो प्रकार का चयन करना होगा। नीचे प्रवाह अनुभाग पर जाएँ. ड्रॉपडाउन से कॉम्प्लीमेंट टोकन चुनें।



  1. अब, आपको एक ट्रिगर चुनना होगा। ट्रिगर जोड़ें पर क्लिक करें. ट्रिगर प्रकार के रूप में प्री-एक्सेस टोकन निर्माण का चयन करें और संबंधित कार्रवाई के रूप में assignRoleAndExperienceClaims का चयन करें।



  1. और अब, आपको ट्रिगर सूचीबद्ध दिखाई देगा।



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

एपीआई प्रोजेक्ट सेट करें

GitHub से प्रोजेक्ट को क्लोन करें:

इस GitHub रिपॉजिटरी से प्रोजेक्ट को क्लोन करने के लिए नीचे दिए गए कमांड को चलाएँ:

  • git clone https://github.com/zitadel/example-fine-grained-authorization.git


प्रोजेक्ट निर्देशिका पर जाएँ:

क्लोनिंग के बाद, प्रोजेक्ट डायरेक्टरी पर जाएँ

  • cd example-fine-grained-authorization


एक पायथन पर्यावरण सेटअप करें:

सुनिश्चित करें कि आपके पास Python 3 और pip स्थापित है। इसे आप चला कर चेक कर सकते हैं

  • python3 --version और
  • pip3 --version

आपके टर्मिनल में. यदि आपके पास पायथन या पाइप स्थापित नहीं है, तो आपको उन्हें स्थापित करना होगा।


इसके बाद, चलाकर इस प्रोजेक्ट के लिए एक नया वर्चुअल वातावरण बनाएं

  • python3 -m venv env .


चलाकर पर्यावरण को सक्रिय करें:

  • विंडोज़ पर: .\env\Scripts\activate
  • यूनिक्स या MacOS पर: source env/bin/activate


इस कमांड को चलाने के बाद, आपके टर्मिनल को यह संकेत देना चाहिए कि आप अब env वर्चुअल वातावरण के अंदर काम कर रहे हैं।


निर्भरताएँ स्थापित करें:

प्रोजेक्ट निर्देशिका में टर्मिनल के साथ (जिसमें require.txt शामिल है), चलाएँ

  • pip3 install -r requirements.txt

आवश्यक निर्भरताएँ स्थापित करने के लिए।


पर्यावरण चर कॉन्फ़िगर करें:

परियोजना को कुछ पर्यावरण चर की आवश्यकता है। .env फ़ाइल में वे मान भरें जो हमने ZITADEL से प्राप्त किए हैं।

 PROJECT_ID="<YOUR PROJECT ID>" ZITADEL_DOMAIN="<YOUR INSTANCE DOMAIN eg https://instance-as23uy.zitadel.cloud>" ZITADEL_TOKEN_URL="<YOUR TOKEN URL eg https://instance-as23uy.zitadel.cloud/oauth/v2/token" CLIENT_ID="<YOUR SERVICE USER'S CLIENT ID FROM THE GENERATED CLIENT CREDENTIALS eg sj_Alice>" CLIENT_SECRET="<YOUR SERVICE USER'S SECRET FROM THE GENERATED CLIENT CREDENTIALS"> ZITADEL_INTROSPECTION_URL="<YOUR INTROSPECTION URL eg https://instance-as23uy.zitadel.cloud/oauth/v2/introspect>" API_CLIENT_ID="<THE CLIENT ID OF YOUR API APPLICATION FOR BASIC AUTH eg 324545668690006737@api>" API_CLIENT_SECRET="<THE CLIENT SECRET OF YOUR API APPLICATION FOR BASIC AUTH>"


एप्लिकेशन चलाएँ:

फ्लास्क एपीआई ( app.py में) सुक्ष्म पहुंच नियंत्रण के लिए JWT टोकन और कस्टम दावों का उपयोग करता है। यह हर अनुरोध पर journalist और editor भूमिका के लिए कस्टम दावा अनुभव_स्तर की जांच करता है, इस जानकारी का उपयोग करके यह तय करता है कि प्रमाणित उपयोगकर्ता अनुरोधित समापन बिंदु तक पहुंच सकता है या नहीं।


ऐप.पी.ई

 from flask import Flask, jsonify from auth import token_required from access_control import authorize_access app = Flask(__name__) # Define the /write_article route. @app.route('/write_article', methods=['POST']) @token_required def write_article(): authorization = authorize_access('write_article') if authorization is not True: return authorization # Resource-specific code goes here... return jsonify({"message": "Article written successfully!"}), 200 # Define the /edit_article route. @app.route('/edit_article', methods=['PUT']) @token_required def edit_article(): authorization = authorize_access('edit_article') if authorization is not True: return authorization # Resource-specific code goes here... return jsonify({"message": "Article edited successfully!"}), 200 # Define the /review_article route. @app.route('/review_articles', methods=['GET']) @token_required def review_article(): authorization = authorize_access('review_article') if authorization is not True: return authorization # Resource-specific code goes here... return jsonify({"message": "Article review accessed successfully!"}), 200 # Define the /publish_article route. @app.route('/publish_article', methods=['POST']) @token_required def publish_article(): authorization = authorize_access('publish_article') if authorization is not True: return authorization # Resource-specific code goes here... return jsonify({"message": "Article published successfully!"}), 200 # Add more endpoints as needed... if __name__ == '__main__': app.run(debug=True)


auth.py

 import os import jwt import requests from functools import wraps from flask import request, jsonify, g ZITADEL_INTROSPECTION_URL = os.getenv('ZITADEL_INTROSPECTION_URL') API_CLIENT_ID = os.getenv('API_CLIENT_ID') API_CLIENT_SECRET = os.getenv('API_CLIENT_SECRET') # This function checks the token introspection and populates the flask.g variable with the user's token def token_required(f): @wraps(f) def decorated(*args, **kwargs): token = request.headers.get('Authorization') if not token: abort(401) # Return status code 401 for Unauthorized if there's no token else: token = token.split(' ')[1] # The token is in the format "Bearer <token>", we want to extract the actual token # Call the introspection endpoint introspection_response = requests.post( ZITADEL_INTROSPECTION_URL, auth=(API_CLIENT_ID, API_CLIENT_SECRET), data={'token': token} ) if not introspection_response.json().get('active', False): return jsonify({"message": "Invalid token"}), 403 # Decode the token and print it for inspection decoded_token = jwt.decode(token, options={"verify_signature": False}) print(f"\n\n***** Decoded Token: {decoded_token} \n\n******") # Add the decoded token to Flask's global context g.token = decoded_token return f(*args, **kwargs) return decorated


access_control.py (नियम इंजन का अनुकरण करने वाला नमूना कोड)

 import base64 import jwt from flask import g, jsonify # The access_requirements dictionary represents your access control rules. access_requirements = { 'write_article': [{'role': 'journalist', 'experience_level': 'junior'}, {'role': 'journalist', 'experience_level': 'intermediate'}, {'role': 'journalist', 'experience_level': 'senior'}], 'edit_article': [{'role': 'editor', 'experience_level': 'junior'}, {'role': 'editor', 'experience_level': 'intermediate'}, {'role': 'editor', 'experience_level': 'senior'}], 'review_articles': [{'role': 'journalist', 'experience_level': 'senior'}, {'role': 'editor', 'experience_level': 'intermediate'}, {'role': 'editor', 'experience_level': 'senior'}], 'publish_article': [{'role': 'journalist', 'experience_level': 'intermediate'}, {'role': 'journalist', 'experience_level': 'senior'}, {'role': 'editor', 'experience_level': 'senior'}] # Add more endpoints as needed... } # This function checks if the user is authorized to access the given endpoint. def authorize_access(endpoint): # We assume that the token has already been decoded in auth.py decoded_token = g.token # Initialize role and experience_level variables role = None experience_level = None for claim, value in decoded_token.items(): if ':experience_level' in claim: role, _ = claim.split(':') experience_level = base64.b64decode(value).decode('utf-8') break # If there's no role in the token, return an error if not role: return jsonify({"message": "Missing role"}), 403 # If there's a role in the token but no experience level, default the experience level to 'junior' if role and not experience_level: experience_level = 'junior' # If there's no role or experience level in the token, return an error if not role or not experience_level: return jsonify({"message": "Missing role or experience level"}), 403 # Get the requirements for the requested endpoint endpoint_requirements = access_requirements.get(endpoint) # If the endpoint is not in the access control list, return an error if not endpoint_requirements: return jsonify({"message": "Endpoint not found in access control list"}), 403 # Check if the user's role and experience level meet the requirements for the requested endpoint for requirement in endpoint_requirements: required_role = requirement['role'] required_experience_level = requirement['experience_level'] # Experience level hierarchy experience_levels = ['junior', 'intermediate', 'senior'] if role == required_role and experience_levels.index(experience_level) >= experience_levels.index(required_experience_level): return True #return jsonify({"message": "Access denied"}), 403 return jsonify({"message": f"Access denied! You are a {experience_level} {role} and therefore cannot access {endpoint}"}), 403


निष्पादित करके फ्लास्क एप्लिकेशन चलाएँ:

python3 app.py


यदि सब कुछ सही ढंग से सेट किया गया है, तो आपका फ्लास्क एप्लिकेशन अब चलना चाहिए।


यह प्रोजेक्ट Python 3 के साथ विकसित और परीक्षण किया गया था, इसलिए सुनिश्चित करें कि आप Python 3 दुभाषिया का उपयोग कर रहे हैं।

एपीआई चलाएँ और परीक्षण करें

एपीआई चलाएँ

  1. सुनिश्चित करें कि आपने रिपॉजिटरी को क्लोन कर लिया है और पहले बताए अनुसार आवश्यक निर्भरताएँ स्थापित कर ली हैं।


  2. एक्सेस टोकन जनरेट करने के लिए client_credentials_token_generator.py स्क्रिप्ट चलाएँ।


    client_credentials_token_generator.py

     import os import requests import base64 from dotenv import load_dotenv load_dotenv() ZITADEL_DOMAIN = os.getenv("ZITADEL_DOMAIN") CLIENT_ID = os.getenv("CLIENT_ID") CLIENT_SECRET = os.getenv("CLIENT_SECRET") ZITADEL_TOKEN_URL = os.getenv("ZITADEL_TOKEN_URL") PROJECT_ID = os.getenv("PROJECT_ID") # Encode the client ID and client secret in Base64 client_credentials = f"{CLIENT_ID}:{CLIENT_SECRET}".encode("utf-8") base64_client_credentials = base64.b64encode(client_credentials).decode("utf-8") # Request an OAuth token from ZITADEL headers = { "Content-Type": "application/x-www-form-urlencoded", "Authorization": f"Basic {base64_client_credentials}" } data = { "grant_type": "client_credentials", "scope": f"openid profile email urn:zitadel:iam:org:project:id:{PROJECT_ID}:aud urn:zitadel:iam:org:projects:roles urn:zitadel:iam:user:metadata" } response = requests.post(ZITADEL_TOKEN_URL, headers=headers, data=data) if response.status_code == 200: access_token = response.json()["access_token"] print(f"Response: {response.json()}") print(f"Access token: {access_token}") else: print(f"Error: {response.status_code} - {response.text}")


    अपना टर्मिनल खोलें और प्रोजेक्ट निर्देशिका पर जाएँ, फिर Python3 का उपयोग करके स्क्रिप्ट चलाएँ:

    python3 client_credentials_token_generator.py


  3. सफल होने पर, यह आपके टर्मिनल पर एक एक्सेस टोकन प्रिंट करेगा। यह वह टोकन है जिसका उपयोग आप एपीआई के लिए अपने अनुरोधों को प्रमाणित करने के लिए करेंगे।


  4. यदि आपने फ्लास्क एपीआई पहले शुरू नहीं किया है, तो प्रोजेक्ट निर्देशिका में एक और टर्मिनल खोलकर एपीआई चलाएं:

    python3 app.py


  5. एपीआई सर्वर अब चालू होना चाहिए और अनुरोध स्वीकार करने के लिए तैयार होना चाहिए।


अब, आप एपीआई के लिए अनुरोध करने के लिए कर्ल या किसी अन्य HTTP क्लाइंट (जैसे पोस्टमैन) का उपयोग कर सकते हैं। चरण 2 में प्राप्त एक्सेस टोकन के साथ कर्ल कमांड में your_access_token बदलना याद रखें।

एपीआई का परीक्षण करें

परिदृश्य 1: कनिष्ठ संपादक एक लेख को संपादित करने का प्रयास करता है (सफलता)


editor भूमिका और junior अनुभव_स्तर वाला उपयोगकर्ता edit_article समापन बिंदु पर कॉल करने का प्रयास करता है।

  • curl -H "Authorization: Bearer <your_access_token>" -X POST http://localhost:5000/edit_article


  • अपेक्षित आउटपुट: {"message": "Article edited successfully"}


परिदृश्य 2: कनिष्ठ संपादक एक लेख प्रकाशित करने का प्रयास करता है (विफलता)

editor भूमिका और junior अनुभव_स्तर वाला उपयोगकर्ता publish_article एंडपॉइंट पर कॉल करने का प्रयास करता है।

  • curl -H "Authorization: Bearer <your_access_token>" -X POST http://localhost:5000/publish_article


  • अपेक्षित आउटपुट: {"message": "Access denied! You are a junior editor and therefore cannot access publish_article"}


परिदृश्य 3: वरिष्ठ पत्रकार एक लेख लिखने का प्रयास करता है (सफलता)

journalist भूमिका और senior अनुभव_स्तर वाला उपयोगकर्ता write_article समापन बिंदु पर कॉल करने का प्रयास करता है।

  • curl -H "Authorization: Bearer <your_access_token>" -X POST http://localhost:5000/write_article

  • अपेक्षित आउटपुट: {"message": "Article written successfully"}


परिदृश्य 4: जूनियर पत्रकार लेखों की समीक्षा करने का प्रयास करता है (विफलता)

journalist भूमिका और 'जूनियर' अनुभव_स्तर वाला उपयोगकर्ता review_articles समापन बिंदु पर कॉल करने का प्रयास करता है।

  • curl -H "Authorization: Bearer <your_access_token>" -X POST http://localhost:5000/review_articles


  • अपेक्षित आउटपुट: {"message": "Access denied! You are a junior journalist and therefore cannot access review_articles"}


परिदृश्य 5: वरिष्ठ संपादक लेखों की समीक्षा करने का प्रयास करते हैं (सफलता)

editor भूमिका और senior अनुभव_स्तर वाला उपयोगकर्ता review_articles समापन बिंदु तक पहुंचने का प्रयास करता है।

  • curl -H "Authorization: Bearer <your_access_token>" -X POST http://localhost:5000/review_articles


  • अपेक्षित आउटपुट: {"message": "Article reviewed successfully"}


परिदृश्य 6: मध्यवर्ती पत्रकार एक लेख प्रकाशित करने का प्रयास करता है (सफलता)

journalist की भूमिका और intermediate अनुभव_स्तर वाला उपयोगकर्ता publish_article एंडपॉइंट तक पहुंचने का प्रयास करता है।

  • curl -H "Authorization: Bearer <your_access_token>" -X POST http://localhost:5000/publish_article


  • अपेक्षित आउटपुट: {"message": "Article published successfully"}

निष्कर्ष

इस लेख में, हमने ZITADEL का उपयोग करके पारंपरिक RBAC से अधिक विस्तृत, सुक्ष्म प्राधिकरण दृष्टिकोण में स्थानांतरित होने के महत्व का पता लगाया।


हमने एबीएसी के लिए गतिशील क्रियाएं, तृतीय-पक्ष टूल के साथ एकीकृत करने की क्षमता जैसी इसकी विशेषताओं का गहराई से अध्ययन किया और देखा कि इन क्षमताओं को वास्तविक दुनिया के परिदृश्य में व्यावहारिक रूप से कैसे लागू किया जा सकता है।


जैसे-जैसे साइबर सुरक्षा की मांग बढ़ती है, ZITADEL जैसे प्लेटफ़ॉर्म जटिल प्राधिकरण चुनौतियों के लिए आवश्यक समाधान प्रदान करते हैं।