कीक्लॉक में संसाधन, स्कोप, अनुमतियां और नीतियां

Question 1

मैं Keycloak के ऑथराइज़ेशन सिस्टम का उपयोग करके एक काफी सरल भूमिका-आधारित अभिगम नियंत्रण प्रणाली बनाना चाहता हूं। Keycloak की जगह सिस्टम हमें "उपयोगकर्ता" बनाने की अनुमति देता है, जो एक या अधिक "समूहों" का सदस्य है। इस विरासत प्रणाली में, एक उपयोगकर्ता को समूह सदस्यता (जहां समूह को अनुमतियाँ दी जाती हैं) या उपयोगकर्ता को अनुमति के प्रत्यक्ष अनुदान के माध्यम से लगभग 250 "क्षमताओं" में से प्रत्येक का उपयोग करने के लिए "अनुमति" दी जाती है।

मैं कीलक प्राधिकरण के लिए विरासत प्रणाली को मैप करना चाहूंगा।

यह मेरे लिए सरल होना चाहिए कि मौजूदा सिस्टम में प्रत्येक "क्षमता" को कीक्लॉक रिसोर्स पर और कीक्लोजेन स्कोप्स के सेट पर मैप करें। उदाहरण के लिए, एक "viewAccount" क्षमता स्पष्ट रूप से एक "खाता" संसाधन और एक "दृश्य" गुंजाइश के लिए मैप करेगी; और एक "लेन-देन" संसाधन के लिए "viewTransaction" नक्शे ... लेकिन यह सिर्फ एक "दृश्य" गुंजाइश बनाने के लिए सबसे अच्छा अभ्यास है, और कई संसाधनों (खाता, लेनदेन, आदि) में इसका उपयोग करें? या मुझे एक "व्यूअकाउंट" स्कोप, एक "व्यूट्रांसैक्शन" स्कोप आदि बनाना चाहिए?

इसी तरह, मैं अनुमतियों को लेकर थोड़ा भ्रमित हूं। संसाधन और दायरे के प्रत्येक व्यावहारिक संयोजन के लिए, क्या अनुमति बनाना सामान्य अभ्यास है? यदि किसी दिए गए संसाधन / कार्यक्षेत्र से मेल खाते कई अनुमतियाँ हैं, तो Keyloloak क्या करता है? मैं अनुमान लगा रहा हूं कि कीक्लोक का इरादा मुझे संसाधनों और स्कोप के खिलाफ अनुमति के मैट्रिक्स को कॉन्फ़िगर करने की अनुमति देना है, इसलिए उदाहरण के लिए मुझे "खातों" तक पहुंचने की अनुमति और "दृश्य" गुंजाइश की अनुमति हो सकती है, इसलिए इसलिए मुझे अनुमति होगी खातों को देखने के लिए

मैं पूछता हूं क्योंकि इस सब का परिणाम यह लगता है कि मेरी पुरानी "व्यूअकाउंट" क्षमता "खाता" संसाधन, "व्यू" गुंजाइश, और "व्यूअकाउंट" अनुमति के साथ समाप्त होती है, जो मुझे लगता है कि मुझे वापस मिल गया था। जो ठीक है, अगर यह सही है।

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

धन्यवाद,

निशान

Question 2

मुझे पता है कि मुझे 2 साल की देर हो चुकी है, लेकिन मुझे लगता है कि मैं जो जानता हूं उसे साझा करूंगा और उम्मीद है कि भविष्य के पाठकों के लिए कुछ दर्द कम होगा। पूर्ण पारदर्शिता- मैं किसी भी तरह से Keycloak / OAuth / OIDC विशेषज्ञ नहीं हूं और मुझे जो भी पता है वह ज्यादातर डॉक्स, किताबें, अच्छे ol 'YouTube को पढ़ने और टूल के साथ खेलने से है।

इस पोस्ट में दो भाग शामिल होंगे:

मैं अपनी क्षमता के अनुसार आपके सभी सवालों का जवाब देने का प्रयास करूंगा
मैं आप सभी को दिखाऊंगा कि कैसे आप इस थ्रेड में कुछ मुख्य अवधारणाओं को बेहतर ढंग से समझने के लिए अलग-अलग ऐप को तैनात करने की आवश्यकता के बिना कीक्लॉक में नीतियों / स्कोप / अनुमतियों के साथ खेल सकते हैं। हालांकि ध्यान दें कि यह ज्यादातर आप सभी को शुरू करने के लिए है। मैं उपयोग कर रहा हूं Keycloak 8.0.0।

भाग I

आरंभ करने से पहले कुछ शब्दावली:

Keycloak में, आप 2 प्रकार की अनुमतियाँ बना सकते हैं: संसाधन-आधारित और स्कोप-आधारित ।
सीधे शब्दों में कहें, Resource-Basedअनुमतियों के लिए, आप इसे सीधे अपने संसाधन पर लागू करते हैं
के लिए Scoped-Basedअनुमति है, आप इसे अपने दायरे (s) या गुंजाइश (रों) पर लागू होते हैं और संसाधन।

क्या यह केवल एक "दृश्य" गुंजाइश बनाने के लिए सबसे अच्छा अभ्यास है, और इसका उपयोग कई संसाधनों (खाता, लेनदेन, आदि) में किया जाता है? या मुझे एक "व्यूअकाउंट" स्कोप, एक "व्यूट्रांसैक्शन" स्कोप आदि बनाना चाहिए?

स्कोप एक संरक्षित संसाधन पर अधिकारों के एक समूह का प्रतिनिधित्व करते हैं। आपके मामले में, आपके पास 2 संसाधन हैं: accountऔर transaction, इसलिए मैं दूसरे दृष्टिकोण की ओर झुकूंगा।

लंबे समय में, एक वैश्विक होने viewअपने सभी संसाधनों के साथ जुड़े गुंजाइश (जैसे account, transaction, customer, settlement...) दोनों का प्रबंधन और सुरक्षा की आवश्यकता को परिवर्तन करने के लिए अनुकूल करने के लिए बनाता है प्राधिकरण मुश्किल।

यहां कुछ उदाहरण दिए गए हैं, जिन्हें आप डिजाइन के लिए महसूस कर सकते हैं

हालांकि ध्यान दें - मैं यह दावा नहीं कर रहा हूं कि आपको संसाधनों में स्कोप साझा नहीं करना चाहिए। तथ्य की बात, Keycloakयह उसी के साथ संसाधनों के लिए अनुमति देता है type। उदाहरण के लिए, आपको किसी दिए गए खाते के तहत लेनदेन को पढ़ने के लिए दोनों viewAccountऔर viewTransactionगुंजाइश की आवश्यकता हो सकती है (आखिरकार आपको लेनदेन देखने के लिए खाते तक पहुंच की आवश्यकता हो सकती है)। आपकी आवश्यकताएं और मानक आपके डिजाइन को बहुत प्रभावित करेंगे।

संसाधन और दायरे के प्रत्येक व्यावहारिक संयोजन के लिए, क्या अनुमति बनाना सामान्य अभ्यास है?

क्षमा याचना, मैं प्रश्न को पूरी तरह से नहीं समझ पा रहा हूं इसलिए मैं थोड़ा व्यापक हो जाऊंगा। किसी को एक्सेस देने / देने से इंकार करने के लिए resource, आपको निम्न करने की आवश्यकता है:

अपनी नीतियों को परिभाषित करें
अपनी अनुमतियों को परिभाषित करें
अपनी नीतियों को अपनी अनुमतियों पर लागू करें
अपनी अनुमति को एक scopeया resource(या दोनों) से संबद्ध करें

प्रभावी होने के लिए नीति प्रवर्तन के लिए। प्राधिकरण प्रक्रिया देखें ।

आप यह सब कैसे स्थापित करते हैं यह पूरी तरह आप पर निर्भर है। आप उदाहरण के लिए कर सकते हैं:

व्यक्तिगत नीतियों को परिभाषित करें, और उचित अनुमति के तहत प्रत्येक नीति को टाई।
बेहतर अभी तक, व्यक्तिगत नीतियों को परिभाषित करें, फिर अपनी सभी संबंधित नीतियों को एक aggregatedनीति (नीतियों की नीति) के तहत समूहित करें और फिर उस समग्र नीति को scope-basedअनुमति के साथ संबद्ध करें । आपके पास यह scoped-basedअनुमति हो सकती है कि संसाधन और उसके संबद्ध क्षेत्र दोनों पर लागू हो।
या, आप दो अलग-अलग प्रकारों का लाभ उठाकर अपनी अनुमतियों को तोड़ सकते हैं। आप resource-basedअनुमति प्रकार के माध्यम से अपने संसाधनों के लिए पूरी तरह से अनुमतियाँ बना सकते हैं , और अलग-अलग अनुमतियों को पूरी तरह से scope-basedअनुमति प्रकार के साथ एक गुंजाइश के साथ जोड़ सकते हैं ।

आपके पास विकल्प हैं।

यदि किसी दिए गए संसाधन / कार्यक्षेत्र से मेल खाते कई अनुमतियाँ हैं, तो Keyloloak क्या करता है?

यह निर्भर करता है

संसाधन सर्वर का Decision Strategy
प्रत्येक अनुमति Decision Strategy
प्रत्येक नीति का Logicमूल्य।

Logicमूल्य जावा के साथ इसी तरह की है !ऑपरेटर। यह या तो हो सकता है Positiveया Negative। जब Logicहै Positive, तो नीति का अंतिम मूल्यांकन अपरिवर्तित रहता है। जब इसका Negativeअंतिम परिणाम नकारा जाता है (जैसे कि यदि कोई नीति गलत का मूल्यांकन करती है और वह Logicहै Negative, तो यह होगा true)। चीजों को सरल रखने के लिए, मान लेते हैं कि Logicहमेशा सेट हैPositive ।

Decision Strategyक्या हम वास्तव में से निपटने के लिए चाहते हैं। Decision Strategyया तो किया जा सकता है Unanimousया Affirmative। डॉक्स से,

निर्णय की रणनीति

यह कॉन्फ़िगरेशन बदलता है कि नीति मूल्यांकन इंजन यह तय करता है कि सभी मूल्यांकन अनुमतियों के परिणाम के आधार पर संसाधन या गुंजाइश दी जानी चाहिए या नहीं। सकारात्मक का मतलब है कि कम से कम एक अनुमति के लिए एक सकारात्मक निर्णय का मूल्यांकन करना चाहिए ताकि संसाधन और उसके दायरे में पहुंच प्रदान की जा सके। सर्वसम्मति का अर्थ है कि अंतिम निर्णय के भी सकारात्मक होने के लिए सभी अनुमतियों को एक सकारात्मक निर्णय का मूल्यांकन करना चाहिए। एक उदाहरण के रूप में, यदि एक ही संसाधन या दायरे के लिए दो अनुमतियाँ संघर्ष में हैं (उनमें से एक पहुंच का उपयोग कर रहा है और दूसरा पहुंच से इनकार कर रहा है), तो संसाधन या गुंजाइश की अनुमति दी जाएगी यदि चुनी गई रणनीति सकारात्मक है। अन्यथा, किसी भी अनुमति से एक एकल इनकार भी संसाधन या दायरे तक पहुंच से इनकार करेगा।

उपरोक्त को बेहतर ढंग से समझने के लिए एक उदाहरण का उपयोग करते हैं। मान लीजिए आप 2 अनुमतियों के साथ एक संसाधन है और किसी संसाधन (याद रखें, कि उपयोग करने के लिए कोशिश कर रहा है Logicहै Positiveसभी नीतियों के लिए)। अभी:

Permission Oneके लिए एक Decision Strategyसेट है Affirmative। इसकी 3 नीतियां भी हैं जहां वे प्रत्येक का मूल्यांकन करते हैं:
- true
- false
- false

चूंकि किसी एक पॉलिसी को सेट किया जाता है true, Permission Oneउसे सेट किया जाता है true(Affirmative - केवल 1 होना चाहिए true)।

Permission Two2 नीतियों के साथ एक Decision Strategyसेट है Unanimous:
- true
- false

इस मामले Permission Twoमें falseचूंकि एक नीति झूठी है (सर्वसम्मति से - उन्हें सभी की आवश्यकता है true)।

अब अंतिम मूल्यांकन आता है । यदि संसाधन सर्वर Decision Strategyसेट है Affirmative, तो उस संसाधन तक पहुँच दी जाएगी क्योंकि Permission Oneहै true। यदि दूसरी ओर, संसाधन सर्वर Decision Strategyपर सेट किया गया है Unanimous, तो प्रवेश निषेध होगा।

देख:

हम इसे फिर से जारी रखेंगे। मैं समझाता हूं कि Decision Strategy भाग II में संसाधन को कैसे सेट किया जाए ।

इसलिए उदाहरण के लिए मुझे "खातों" का उपयोग करने की अनुमति हो सकती है और "दृश्य" गुंजाइश की अनुमति हो सकती है, इसलिए इसलिए मुझे खातों को देखने की अनुमति होगी?

छोटा जवाब हां है। अब, इस पर थोड़ा विस्तार करें :)

यदि आपके पास निम्न परिदृश्य है:

संसाधन सर्वर का Decision Strategyसेट UnanimousयाAffirmative
account/{id}संसाधन तक पहुंचने की अनुमति हैtrue
viewदायरे तक पहुंचने की अनुमति हैtrue

खाता देखने के लिए आपको पहुंच प्रदान की जाएगी।

true+ के नीचे या के trueबराबर है । trueAffirmativeUnanimous Decision Strategy

अब अगर आपके पास यह है

संसाधन सर्वर पर Decision StrategyसेटAffirmative
account/{id}संसाधन तक पहुंचने की अनुमति हैtrue
viewदायरे तक पहुंचने की अनुमति हैfalse

खाता देखने के लिए भी आपको पहुंच प्रदान की जाएगी।

true+ falseहै trueके तहत Affirmativeरणनीति।

यहां मुद्दा यह है कि किसी दिए गए संसाधन तक पहुंच भी आपके सेटअप पर निर्भर करती है इसलिए सावधान रहें क्योंकि आप दूसरा परिदृश्य नहीं चाहते हैं।

लेकिन क्या मैं सही हूं कि इसका मतलब यह है कि मुझे प्रत्येक विरासत समूहों के लिए एक नीति की आवश्यकता है जो एक उपयोगकर्ता का हो सकता है?

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

उदाहरण के लिए, यदि मेरी "हेल्पडेस्क" भूमिका है, तो मुझे "हेल्पडेस्क सदस्यता" नीति की आवश्यकता है, जिसे मैं फिर "व्यूअकाउंट" अनुमति में जोड़ सकता हूं। क्या ये सही है?

बहुत ज्यादा। ऐसे कई तरीके हैं जिनसे आप इसे सेट कर सकते हैं। उदाहरण के लिए, आप कर सकते हैं:

अपना संसाधन (जैसे /account/{id}) बनाएँ और इसे account:viewकार्यक्षेत्र के साथ जोड़ें ।
भूमिका-आधारित नीति बनाएं और helpdeskउस नीति के तहत भूमिका जोड़ें
Scope-Basedनामक एक अनुमति बनाएँ viewAccountऔर इसके साथ टाई करें scope, resourceऔरpolicy

हम भाग II में कुछ इसी तरह की स्थापना करेंगे।

भाग द्वितीय

कीक्लोक में एक छोटा सा उपकरण है जो आपको अपनी सभी नीतियों का परीक्षण करने की अनुमति देता है। बेहतर अभी तक, आपको वास्तव में किसी अन्य एप्लिकेशन सर्वर को स्पिन करने की आवश्यकता नहीं है और काम करने के लिए एक अलग ऐप को तैनात करना होगा।

यहाँ वह परिदृश्य है जिसे हम सेट करेंगे:

हम एक नया क्षेत्र बनाएँगे जिसे कहा जाता है stackoverflow-demo
हम bank-apiउस दायरे में एक क्लाइंट बनाएंगे
हम /account/{id}उस क्लाइंट के लिए बुलाए गए संसाधन को परिभाषित करेंगे
की गुंजाइश account/{id}होगीaccount:view
हम bobनए दायरे के तहत एक उपयोगकर्ता बनाएंगे
हम भी तीन भूमिकाओं में पैदा हो जाएगी: bank_teller, account_ownerऔरuser
- हम bobकिसी भी भूमिका से नहीं जुड़ेंगे। अभी इसकी जरूरत नहीं है।
हम निम्नलिखित दो Role-Basedनीतियां निर्धारित करेंगे :
- bank_tellerऔर संसाधन account_ownerतक पहुंच है/account/{id}
- account_owneraccount:viewदायरे तक पहुँच है
- user संसाधन या दायरे तक पहुंच नहीं है
हम इस Evaluateटूल के साथ खेलेंगे कि कैसे पहुंच प्रदान की जा सकती है या अस्वीकार की जा सकती है।

मुझे माफ कर दो, यह उदाहरण अवास्तविक है लेकिन मैं बैंकिंग क्षेत्र से परिचित नहीं हूँ :)

कीकलोक सेटअप

डाउनलोड करें और Keycloak चलाएँ

cd tmp
wget https://downloads.jboss.org/keycloak/8.0.0/keycloak-8.0.0.zip 
unzip keycloak-8.0.0.zip
cd keycloak-8.0.0/bin
./standalone.sh

प्रारंभिक व्यवस्थापक उपयोगकर्ता बनाएँ

के लिए जाओ http://localhost:8080/auth
Administration Consoleलिंक पर क्लिक करें
व्यवस्थापक उपयोगकर्ता बनाएं और लॉगिन करें

यात्रा प्रारंभ करना अधिक जानकारी के लिए। हमारे उद्देश्यों के लिए, उपरोक्त पर्याप्त है।

मंच की स्थापना

एक नया क्षेत्र बनाएँ

अपने माउस को masterदायरे में घुमाएं और Add Realmबटन पर क्लिक करें।
stackoverflow-demoनाम के रूप में दर्ज करें ।
पर क्लिक करें Create।
शीर्ष बाएं को अब दायरे के stackoverflow-demoबजाय कहना चाहिए master।

एक नया क्षेत्र बनाना देखें

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

Usersबाईं ओर दिए गए लिंक पर क्लिक करें
Add Userबटन पर क्लिक करें
दर्ज करें username(जैसे bob)
सुनिश्चित करें कि User Enabledचालू है
क्लिक Save

नया उपयोगकर्ता बनाना देखें

नई भूमिकाएँ बनाएँ

पर क्लिक करें Rolesलिंक
पर क्लिक करें Add Role
निम्नलिखित भूमिकाओं जोड़ें: bank_teller, account_ownerऔरuser

फिर से, नहीं अपने उपयोगकर्ता को भूमिकाओं के साथ । हमारे उद्देश्यों के लिए, इसकी आवश्यकता नहीं है।

रोल्स देखें

एक ग्राहक बनाएँ

पर क्लिक करें Clientsलिंक
पर क्लिक करें Create
दर्ज bank-apiकरने के लिएClient ID
के लिए Root URLप्रवेशhttp://127.0.0.1:8080/bank-api
पर क्लिक करें Save
सुनिश्चित करें कि Client Protocolहैopenid-connect
बदले Access Typeके लिएconfidential
बदलें Authorization Enabledकरने के लिएOn
नीचे स्क्रॉल करें और हिट करें Save। एक नयाAuthorizationशीर्ष पर टैब दिखाई देना चाहिए।
Authorizationटैब पर क्लिक करें और फिरSettings
सुनिश्चित करें कि Decision Strategyसेट किया गया हैUnanimous
- यह संसाधन सर्वर है Decision Strategy

देख:

कस्टम स्कोप बनाएँ

Authorizationटैब पर क्लिक करें
पृष्ठ को लाने के लिए Authorization Scopes> पर क्लिक करेंCreateAdd Scope
दर्ज account:viewनाम और enter दबाएं।

"खाता संसाधन देखें" बनाएं

Authorizationऊपर दिए गए लिंक पर क्लिक करें
पर क्लिक करें Resources
पर क्लिक करें Create
View Account Resourceदोनों के लिए दर्ज करें NameऔरDisplay name
दर्ज account/{id}करने के लिएURI
टेक्स्ट बॉक्स account:viewमें दर्ज करेंScopes
क्लिक Save

संसाधन बनाना देखें

अपनी नीतियां बनाएं

फिर से Authorizationटैब के नीचे , पर क्लिक करेंPolicies
का चयन करें RoleसेCreate Policyड्रॉपडाउन
में Nameअनुभाग, टाइप करेंOnly Bank Teller and Account Owner Policy
के तहत Realm Rolesचुनिंदा दोनों bank_tellerऔर account_ownerभूमिका
सुनिश्चित करें कि Logicसेट किया गया हैPositive
क्लिक Save
Policiesलिंक पर क्लिक करें
ड्रॉपडाउन Roleसे फिर से चुनें Create Policy।
इस समय के लिए उपयोग Only Account Owner PolicyकरेंName
Realm Rolesचयन के तहतaccount_owner
सुनिश्चित करें कि Logicसेट किया गया हैPositive
क्लिक Save
Policiesशीर्ष पर दिए गए लिंक पर क्लिक करें , आपको अब अपनी नई बनाई गई नीतियों को देखना चाहिए।

भूमिका-आधारित नीति देखें

ध्यान दें कि कीक्लॉक में बहुत अधिक शक्तिशाली नीतियां हैं। प्रबंध नीतियां देखें

संसाधन-आधारित अनुमति बनाएँ

फिर से Authorizationटैब के नीचे , पर क्लिक करेंPermissions
चुनते हैं Resource-Based
के लिए टाइप View Account Resource PermissionकरेंName
Resourcesप्रकार के तहतView Account Resource Permission
Apply Policyचयन के तहतOnly Bank Teller and Account Owner Policy
सुनिश्चित करें कि Decision Strategyसेट किया गया हैUnanimous
क्लिक Save

संसाधन-आधारित अनुमतियाँ बनाएँ देखें

काहे का ...

संसाधन-आधारित अनुमति का मूल्यांकन

Authorizationटैब के नीचे फिर से चुनेंEvaluate
के तहत Userदर्ज करेंbob
Rolesचयन के तहतuser
- यह वह जगह है जहाँ हम अपने उपयोगकर्ता को अपनी बनाई भूमिकाओं के साथ जोड़ेंगे।
Resourcesचयन करें View Account Resourceऔर क्लिक करें के तहतAdd
मूल्यांकन पर क्लिक करें।
View Account Resource with scopes [account:view]परिणाम देखने के लिए विस्तृत करें और आपको देखना चाहिए DENY।

यह समझ में आता है क्योंकि हम केवल दो भूमिकाओं को उस संसाधन तक पहुँच की अनुमति देते हैं Only Bank Teller and Account Owner Policy। चलिए यह परीक्षण करते हैं यह सुनिश्चित करने के लिए कि यह सच है!
Backमूल्यांकन परिणाम के ठीक ऊपर दिए गए लिंक पर क्लिक करें
बॉब की भूमिका बदलें account_ownerऔर उस पर क्लिक करें Evaluate। अब आपको परिणाम को देखना चाहिए PERMIT। यदि आप वापस जाते हैं और भूमिका को बदलते हैं तो समान व्यवहार करेंbank_teller

मूल्यांकन और परीक्षण नीतियां देखें

स्कोप-आधारित अनुमति बनाएँ

Permissionsअनुभाग पर वापस जाएं
ड्रॉपडाउन के Scope-Basedतहत इस समय का चयन करें Create Permission।
के तहत Name, दर्ज करेंView Account Scope Permission
के तहत Scopes, दर्ज करेंaccount:view
के तहत Apply Policy, दर्ज करेंOnly Account Owner Policy
सुनिश्चित करें कि Decision Strategyसेट किया गया हैUnanimous
क्लिक Save

स्कोप-आधारित अनुमतियां बनाना देखें

दूसरा टेस्ट रन

हमारे नए परिवर्तनों का मूल्यांकन

Authorizationअनुभाग पर वापस जाएं
पर क्लिक करें Evaluate
उपयोगकर्ता होना चाहिए bob
भूमिकाएं होनी चाहिए bank_teller
संसाधन होना चाहिए View Account Resourceऔर क्लिक करना चाहिएAdd
पर क्लिक करें Evaluateऔर हमें मिलना चाहिए DENY।
- फिर से इस पर कोई आश्चर्य नहीं होना चाहिए क्योंकि इस bank_tellerतक पहुंच resourceनहीं है लेकिन नहीं है scope। यहाँ एक अनुमति सत्य का मूल्यांकन करती है, और दूसरा असत्य का। यह देखते हुए कि संसाधन सर्वर Decision Strategyपर सेट किया गया है Unanimous, अंतिम निर्णय है DENY।
पर क्लिक करें Settingsके तहत Authorizationटैब, और बदलने Decision Strategyके लिए Affirmativeऔर 1-6 चरणों में वापस जाने के लिए फिर से। इस बार, अंतिम परिणाम होना चाहिए PERMIT(एक अनुमति सत्य है, इसलिए अंतिम निर्णय सत्य है)।
पूर्णता की खातिर, संसाधन सर्वर को Decision Strategyवापस चालू करें Unanimous। पुन: 6 के माध्यम से चरण 1 पर वापस जाएं लेकिन इस बार, भूमिका निर्धारित करें account_owner। इस बार, अंतिम परिणाम फिर से है PERMITजो समझ में आता है, यह देखते हुए कि account_ownerदोनों की पहुंच है resourceऔर scope।

नीट :) आशा है कि यह मदद करता है।

Question 3

मैं शुद्ध HTTP विधियों के माध्यम से प्राधिकरण को लागू करना चाह रहा था, एडेप्टर का उपयोग किए बिना, क्योंकि Lua में एडॉप्टर नहीं था। आशा है कि यह उत्तर गैर-एडाप्टर आधारित विधि की तलाश में लोगों की मदद करता है।

यदि आप एडॉप्टर की तलाश कर रहे हैं तो क्विक स्टार्ट गाइड शुरू करने के लिए सबसे अच्छी जगह है। विशेष रूप से स्प्रिंग बूट ऑर्ट्ज़ उदाहरण ।

शुद्ध HTTP आधारित कार्यान्वयन के लिए:

चरण 1:

कीक्लॉक एडमिन UI में नीतियों और अनुमति को परिभाषित करें

चरण 2

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

{
  "policy-enforcer": {
    "user-managed-access" : {},
    "enforcement-mode" : "ENFORCING"
    "paths": [
      {
        "path" : "/someUri/*",
        "methods" : [
          {
            "method": "GET",
            "scopes" : ["urn:app.com:scopes:view"]
          },
          {
            "method": "POST",
            "scopes" : ["urn:app.com:scopes:create"]
          }
        ]
      }
    ]
  }
}

यदि आप एक एडाप्टर का उपयोग कर रहे हैं और पथ या संसाधन को निर्दिष्ट नहीं करते हैं, तो एडाप्टर आंतरिक रूप से कीस्कोक से पथ और संसाधनों की खोज करेगा ।

चरण 3:

अनुमतियाँ प्राप्त करने या उनका मूल्यांकन करने के लिए टोकन समापन बिंदु का उपयोग करें । आप response_modeअंतिम निर्णय प्राप्त करने के लिए या पूरी अनुमति प्राप्त करने के लिए पैरामीटर का उपयोग कर सकते हैं ।

curl -X POST \
  http://${host}:${port}/auth/realms/${realm}/protocol/openid-connect/token \
  -H "Authorization: Bearer ${access_token}" \
  --data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \
  --data "permission=Resource A#Scope A"

यदि प्राधिकरण अनुरोध किसी अनुमति के लिए मैप नहीं करता है, तो 403इसके बजाय एक HTTP स्थिति कोड लौटाया जाता है।