🕶️ 👎 👨🏻‍🏭 माइक्रो सर्विस पर एसएसओ। हम Keycloak का उपयोग करते हैं। भाग संख्या १ ⬅️ 👨🏽‍💻 👩🏾‍✈️

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

Keycloak रेडहैट द्वारा समर्थित प्रमाणीकरण और अभिगम नियंत्रण के लिए एक खुला स्रोत उत्पाद है। यह एसएसओ - आरएच-एसएसओ का उपयोग करके कंपनी के उत्पादों का आधार है।

मूल अवधारणा

इससे पहले कि आप निर्णय और दृष्टिकोण से निपटना शुरू करें, आपको प्रक्रियाओं की शर्तों और अनुक्रम को निर्धारित करना चाहिए:

पहचान किसी विषय को उसके पहचानकर्ता द्वारा पहचानने की प्रक्रिया है (दूसरे शब्दों में, यह एक नाम, लॉगिन या संख्या निर्धारित कर रहा है)।

प्रमाणीकरण एक प्रमाणीकरण प्रक्रिया है (उपयोगकर्ता को पासवर्ड से सत्यापित किया जाता है, एक पत्र इलेक्ट्रॉनिक हस्ताक्षर द्वारा सत्यापित किया जाता है, आदि)

प्राधिकरण एक संसाधन (उदाहरण के लिए, ईमेल) तक पहुंच का प्रावधान है।

कीक्लोक आइडेंटिटी ब्रोकर

कीकोलोक एक खुला स्रोत पहचान और एक्सेस प्रबंधन समाधान है जिसे आईसीएस में उपयोग के लिए डिज़ाइन किया गया है जहां माइक्रोसिस्ट आर्किटेक्चर पैटर्न का उपयोग किया जा सकता है।

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

कीलक में समर्थित बुनियादी कार्यक्षमता:

ब्राउज़र-आधारित अनुप्रयोगों के लिए सिंगल-साइन ऑन और सिंगल-साइन आउट।
OpenID / OAuth 2.0 / SAML के लिए समर्थन।
पहचान ब्रोकरिंग - बाहरी ओपनआईडी कनेक्ट या एसएएमएल पहचान प्रदाताओं का उपयोग करके प्रमाणीकरण।
सामाजिक लॉगिन - उपयोगकर्ता की पहचान के लिए Google, GitHub, फेसबुक, ट्विटर के लिए समर्थन।
User Federation – LDAP Active Directory .
Kerberos bridge – Kerberos .
Admin Console — Web.
Account Management Console – .
.
2FA Authentication – TOTP/HOTP Google Authenticator FreeOTP.
Login Flows – , .
Session Management – .
Token Mappers – , .
realm, application .
CORS Support – CORS.
Service Provider Interfaces (SPI) – SPI, : , , .
JavaScript applications, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
, OpenID Connect Relying Party library SAML 2.0 Service Provider Library.
plugins.

CI / CD प्रक्रियाओं के लिए, साथ ही Keycloak में प्रबंधन प्रक्रियाओं के स्वचालन के लिए, REST API / JAVA API का उपयोग किया जा सकता है। प्रलेखन इलेक्ट्रॉनिक रूप में उपलब्ध है:

REST API https://www.keycloak.org/docs-api/8.0/rest-api/index.html
JAVA API https://www.keycloak.org/docs-api/8.0-javadocs /index.html

एंटरप्राइज आइडेंटिटी प्रोवाइडर्स (ऑन-प्रिमाइस)

उपयोगकर्ता फेडरेशन सेवाओं के माध्यम से उपयोगकर्ताओं को प्रमाणित करने की क्षमता।

पास-थ्रू प्रमाणीकरण का भी उपयोग किया जा सकता है - यदि उपयोगकर्ता कर्बेरोस (LDAP या AD) के साथ कार्यस्थानों पर प्रमाणीकरण करते हैं, तो उन्हें अपने उपयोगकर्ता नाम और पासवर्ड को फिर से प्रदान किए बिना स्वचालित रूप से Keycloak पर प्रमाणित किया जा सकता है।

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

समर्थित DBMS की सूची व्यापक है और इसमें शामिल हैं: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle और अन्य। फिलहाल सबसे अधिक परीक्षण किया गया है Oracle 12C रिलीज़ 1 आरएसी और गैलेरा 3.12 क्लस्टर मारियाबीडी 10.1.19 के लिए।

पहचान प्रदाता - सामाजिक लॉगिन

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

उपयोगकर्ताओं को प्रमाणित करने के लिए, OpenID / SAML पहचान प्रदाता का उपयोग करना संभव है।

कीलक में OAuth2 का उपयोग करते हुए विशिष्ट प्राधिकरण परिदृश्य

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

इम्प्लिक्ट फ्लो - मोबाइल या वेब एप्लिकेशन (उपयोगकर्ता के डिवाइस पर चलने वाले एप्लिकेशन) द्वारा उपयोग किया जाता है।

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

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

OAuth2 विनिर्देश
RFC-6749
RFC-8252 RFC-6819 में वर्णित है

JWT टोकन और इसके फायदे

JWT (JSON वेब टोकन) एक खुला मानक ( https://tools.ietf.org/html/rfc7519 ) है जो JSON ऑब्जेक्ट के रूप में पार्टियों के बीच जानकारी को सुरक्षित रूप से स्थानांतरित करने के लिए एक कॉम्पैक्ट और स्टैंडअलोन विधि को परिभाषित करता है।

मानक के अनुसार, डॉट्स द्वारा अलग किए गए बेस -64 प्रारूप में टोकन में तीन भाग होते हैं। पहले भाग को हेडर कहा जाता है, जिसमें एक डिजिटल हस्ताक्षर प्राप्त करने के लिए टोकन के प्रकार और हैश एल्गोरिथम का नाम होता है। दूसरा भाग बुनियादी जानकारी (उपयोगकर्ता, गुण आदि) को संग्रहीत करता है। तीसरा भाग एक डिजिटल हस्ताक्षर है।

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

एक ताज़ा टोकन एक टोकन है जो ग्राहकों को उनके जीवनकाल की समाप्ति के बाद नए एक्सेस टोकन का अनुरोध करने की अनुमति देता है। ये टोकन आमतौर पर लंबी अवधि के लिए जारी किए जाते हैं।

माइक्रोसैस आर्किटेक्चर में आवेदन के मुख्य लाभ:

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

JWT टोकन - रचना

हेडर - डिफ़ॉल्ट रूप से, हेडर में केवल टोकन का प्रकार और एन्क्रिप्शन के लिए उपयोग किया जाने वाला एल्गोरिदम होता है।

टोकन का प्रकार "टाइप" कुंजी में संग्रहीत है। JWT में "टाइप" कुंजी को अनदेखा किया गया है। यदि टाइप कुंजी मौजूद है, तो इसका मान JWT होना चाहिए ताकि यह इंगित किया जा सके कि यह ऑब्जेक्ट JSON वेब टोकन है।

दूसरी एल्ग कुंजी टोकन को एन्क्रिप्ट करने के लिए उपयोग किए जाने वाले एल्गोरिदम को परिभाषित करती है। डिफ़ॉल्ट रूप से, इसे HS256 पर सेट किया जाना चाहिए। शीर्षलेख को base64 में एन्कोड किया गया है।

{"alg": "HS256", "टाइप": "JWT"}
पेलोड (सामग्री) - पेलोड किसी भी जानकारी को संग्रहीत करता है जिसे सत्यापित करने की आवश्यकता होती है। पेलोड में प्रत्येक कुंजी को "विवरण" के रूप में जाना जाता है। उदाहरण के लिए, आवेदन केवल आमंत्रण (बंद प्रोमो) द्वारा दर्ज किया जा सकता है। जब हम किसी को भाग लेने के लिए आमंत्रित करना चाहते हैं, तो हम उसे निमंत्रण पत्र भेजते हैं। यह सत्यापित करना महत्वपूर्ण है कि ईमेल पता उस व्यक्ति का है जो आमंत्रण स्वीकार करता है, इसलिए हम इस पते को पेलोड में शामिल करेंगे, इसके लिए हम इसे "ई-मेल" कुंजी में सहेजेंगे

{"ईमेल": "example@x5.ru"}
पेलोड में चाबियाँ मनमानी हो सकती हैं। हालाँकि, कुछ आरक्षित हैं:

iss (जारीकर्ता) - उस एप्लिकेशन को परिभाषित करता है जिससे टोकन भेजा जाता है।
उप (विषय) - टोकन के विषय को परिभाषित करता है।
aud (Audience) – URI, . JWT , — .
exp (Expiration Time) — , . JWT , . Exp unix .
nbf (Not Before) — unix , , .
iat (Issued At) — , JWT. iat unix .
Jti (JWT ID) — , c .

यह समझना महत्वपूर्ण है कि पेलोड एन्क्रिप्टेड रूप में प्रेषित नहीं किया गया है (हालांकि टोकन को एम्बेड किया जा सकता है और फिर एन्क्रिप्टेड डेटा को प्रसारित करना संभव है)। इसलिए, इसमें किसी भी गुप्त जानकारी को संग्रहीत करना असंभव है। शीर्षलेख की तरह, पेलोड base64 में इनकोड किया गया है।
हस्ताक्षर - जब हमारे पास एक हेडर और पेलोड है, तो हम हस्ताक्षर की गणना कर सकते हैं।

Base64 एन्कोडेड: हेडर और पेलोड लिया जाता है, उन्हें डॉट के माध्यम से एक लाइन में जोड़ा जाता है। फिर इस लाइन और गुप्त कुंजी को हेडर में निर्दिष्ट एन्क्रिप्शन एल्गोरिथ्म के इनपुट पर भेजा जाता है (कुंजी "एल्ग")। कुंजी किसी भी स्ट्रिंग हो सकती है। लंबे समय तक तार बेहतर होंगे, क्योंकि मैच के लिए अधिक समय लगेगा।

{"alg": "RSA1_5", "पेलोड": "A128CBC-HS256" "

कीक्लोक फेलओवर क्लस्टर आर्किटेक्चर

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

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

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

असफल-सुरक्षित स्थापना का सबसे सरल उदाहरण।

एकल क्लस्टर का उपयोग करने के क्या लाभ हैं:

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

क्लस्टर की योजना बनाते समय विचार करने योग्य बातें

डीबीएमएस

Keycloak एक DBMS प्रबंधन प्रणाली को बचाने के लिए उपयोग करता है: लोकों, ग्राहकों, उपयोगकर्ताओं, आदि
DBMSs की एक विस्तृत श्रृंखला समर्थित है: MS SQL, Oracle, MySQL, PostgreSQL। Keycloak अपने स्वयं के अंतर्निहित रिलेशनल डेटाबेस के साथ आता है। गैर-लोडेड वातावरण जैसे कि विकास वातावरण की सिफारिश की जाती है।

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

वितरित कैश (Infinspan)

क्लस्टर को सही तरीके से काम करने के लिए, JBoss डेटा ग्रिड का उपयोग करके निम्नलिखित कैश प्रकारों का अतिरिक्त सिंक्रनाइज़ेशन आवश्यक है:

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

एक्शन टोकन - परिदृश्यों के लिए उपयोग किया जाता है जब उपयोगकर्ता को एसिंक्रोनसली (ईमेल के माध्यम से) कार्रवाई की पुष्टि करने की आवश्यकता होती है। उदाहरण के लिए, पासवर्ड भूल जाने की स्थिति के दौरान, एक्शनटॉकेन्स इंफ़िनस्पैन कैश का उपयोग मेटाडेटा को संबंधित एक्शन मार्करों के बारे में ट्रैक करने के लिए किया जाता है जो पहले से ही उपयोग किए गए हैं, इसलिए इसका पुन: उपयोग नहीं किया जा सकता है।

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

कार्य - केवल क्लस्टर नोड्स और डेटा केंद्रों के बीच अमान्य संदेश भेजने के लिए उपयोग किया जाता है।

उपयोगकर्ता सत्र - उपयोगकर्ता सत्रों के बारे में डेटा को बचाने के लिए उपयोग किया जाता है जो उपयोगकर्ता के ब्राउज़र सत्र के लिए मान्य हैं। कैश को अंतिम उपयोगकर्ता और एप्लिकेशन से HTTP अनुरोधों को संभालना होगा।

जानवर बल संरक्षण - असफल लॉगिन डेटा को ट्रैक करने के लिए उपयोग किया जाता है।

भार संतुलन

लोड बैलेंसर की क्लोक में एक एकल प्रविष्टि बिंदु है और इसे चिपचिपा सत्रों का समर्थन करना चाहिए।

अनुप्रयोग सर्वर

वे आपस में घटकों की बातचीत को नियंत्रित करने के लिए उपयोग किए जाते हैं और मौजूदा स्वचालन उपकरण और गतिशील रूप से स्केलिंग बुनियादी ढांचे स्वचालन उपकरण का उपयोग करके वर्चुअलाइज्ड या कंटेनरीकृत किया जा सकता है। OpenShift, Kubernetes, Rancher में सबसे आम तैनाती परिदृश्य।

इस पर, पहला भाग - सैद्धांतिक - खत्म हो गया है। निम्नलिखित लेखों की श्रृंखला में, विभिन्न पहचान प्रदाताओं और कॉन्फ़िगरेशन के उदाहरणों के साथ एकीकरण के उदाहरणों पर चर्चा की जाएगी।

माइक्रो सर्विस पर एसएसओ। हम Keycloak का उपयोग करते हैं। भाग संख्या १