ڪنهن به وڏي ڪمپني ۾، ۽ X5 پرچون گروپ ڪو به استثنا نه آهي، جيئن اهو ترقي ڪري ٿو، منصوبن جو تعداد جيڪو صارف جي اجازت جي ضرورت آهي وڌائي ٿو. وقت گذرڻ سان گڏ، صارفين جي هڪ ايپليڪيشن کان ٻئي تائين بيحد منتقلي جي ضرورت هوندي آهي، ۽ پوء هڪ واحد سنگل-آن (SSO) سرور استعمال ڪرڻ جي ضرورت آهي. پر ڇا ٿيندو جڏهن سڃاڻپ فراهم ڪندڙ جهڙوڪ AD يا ٻيا جن وٽ اضافي خاصيتون نه هونديون آهن اڳ ۾ ئي مختلف منصوبن ۾ استعمال ٿيل آهن. سسٽم جو هڪ طبقو سڏيو ويندو آهي "سڃاڻپ بروکرز" بچاء لاء ايندا. سڀ کان وڌيڪ فنڪشنل ان جا نمائندا آهن، جهڙوڪ Keycloak، Gravitee Access Management، وغيره. اڪثر ڪري، استعمال جا ڪيس مختلف ٿي سگهن ٿا: مشين جي وچ ۾ رابطي، صارف جي شموليت، وغيره. حل کي لازمي طور تي لچڪدار ۽ اسپيبلبل ڪارڪردگي جي حمايت ڪرڻ گهرجي جيڪا سڀني ضرورتن کي گڏ ڪري سگهي ٿي، ۽ اهڙا حل اسان جي ڪمپني وٽ هاڻي هڪ اشارو بروکر آهي - Keycloak.
Keycloak هڪ اوپن سورس جي سڃاڻپ ۽ رسائي ڪنٽرول پراڊڪٽ آهي جيڪو ريڊ هيٽ پاران سنڀاليو ويو آهي. اهو SSO - RH-SSO استعمال ڪندي ڪمپني جي شين جو بنياد آهي.
بنيادي تصورات
ان کان اڳ جو توهان حل ۽ طريقن سان معاملو ڪرڻ شروع ڪيو، توهان کي عمل جي اصطلاحن ۽ ترتيب ۾ فيصلو ڪرڻ گهرجي:
سڃاڻپ اهو هڪ طريقو آهي جيڪو هڪ مضمون جي سڃاڻپ ڪندڙ طرفان سڃاڻپ ڪري ٿو (ٻين لفظن ۾، اهو نالو، لاگ ان يا نمبر جي تعريف آهي).
تصديق - هي هڪ تصديق جو طريقو آهي (يوزر کي پاسورڊ سان چيڪ ڪيو ويو آهي، خط هڪ اليڪٽرانڪ دستخط سان چيڪ ڪيو ويو آهي، وغيره)
اختيار ڏيڻ - هڪ وسيلن تائين رسائي فراهم ڪري رهيو آهي (مثال طور، اي ميل).
سڃاڻپ بروکر Keycloak
چاٻي IS ۾ استعمال لاءِ ٺهيل هڪ اوپن سورس جي سڃاڻپ ۽ رسائي جي انتظام جو حل آهي جتي microservice فن تعمير جا نمونا استعمال ڪري سگھجن ٿا.
Keycloak خاصيتون پيش ڪري ٿو جهڙوڪ سنگل سائن آن (SSO)، بروکر ٿيل سڃاڻپ ۽ سماجي لاگ ان، يوزر فيڊريشن، ڪلائنٽ اڊاپٽر، ايڊمن ڪنسول ۽ اڪائونٽ مئنيجمينٽ ڪنسول.
بنيادي ڪارڪردگي Keycloak ۾ سپورٽ ڪئي وئي:
- برائوزر ايپليڪيشنن لاءِ سنگل سائن آن ۽ سنگل سائن آئوٽ.
- OpenID/OAuth 2.0/SAML لاءِ سپورٽ.
- سڃاڻپ بروکرنگ - خارجي OpenID Connect يا SAML سڃاڻپ فراهم ڪندڙ استعمال ڪندي تصديق.
- سوشل لاگ ان - گوگل، گيٽ هب، فيسبوڪ، ٽوئيٽر سپورٽ صارف جي سڃاڻپ لاءِ.
- يوزر فيڊريشن - صارفين جي هم وقت سازي LDAP ۽ Active Directory سرورز ۽ ٻين سڃاڻپ فراهم ڪندڙن کان.
- Kerberos پل - خودڪار صارف جي تصديق لاءِ Kerberos سرور استعمال ڪندي.
- Admin Console - ويب ذريعي سيٽنگون ۽ حل اختيارن جي متحد انتظام لاءِ.
- اڪائونٽ مينيجمينٽ ڪنسول - صارف جي پروفائل جي خود انتظام لاء.
- ڪمپني جي ڪارپوريٽ سڃاڻپ جي بنياد تي حل جي حسب ضرورت.
- 2FA تصديق - TOTP/HOTP سپورٽ Google Authenticator يا FreeOTP استعمال ڪندي.
- لاگ ان فلوز - صارف جي خود-رجسٽريشن، پاسورڊ وصولي ۽ ري سيٽ، ۽ ٻيا ممڪن آهن.
- سيشن مئنيجمينٽ - منتظمين صارف سيشن کي ھڪڙي نقطي کان منظم ڪري سگھن ٿا.
- ٽوڪن ميپرز - ٽوڪن لاءِ صارف جون خاصيتون، ڪردار ۽ ٻيون گهربل خاصيتون پابند ڪرڻ.
- دائري، ايپليڪيشن ۽ استعمال ڪندڙن ۾ لچڪدار پاليسي جو انتظام.
- CORS سپورٽ - ڪلائنٽ ايڊاپٽرز ۾ بلٽ ان CORS سپورٽ آھي.
- سروس فراهم ڪندڙ انٽرفيس (SPI) - SPIs جو هڪ وڏو تعداد جيڪو توهان کي سرور جي مختلف حصن کي ترتيب ڏيڻ جي اجازت ڏئي ٿو: تصديق جي وهڪري، سڃاڻپ فراهم ڪندڙ، پروٽوڪول ميپنگ، ۽ وڌيڪ.
- جاوا اسڪرپٽ ايپليڪيشنن لاءِ ڪلائنٽ اڊاپٽر، WildFly، JBoss EAP، Fuse، Tomcat، Jetty، Spring.
- مختلف ايپليڪيشنن سان ڪم ڪرڻ لاءِ سپورٽ جيڪي سپورٽ ڪن ٿيون OpenID Connect Relying Party Library يا SAML 2.0 Service Provider Library.
- پلگ ان استعمال ڪندي وڌائڻ لائق.
CI / CD جي عملن لاءِ، گڏوگڏ ڪيڪلوڪ ۾ انتظامي عملن جي آٽوميشن لاءِ، REST API / JAVA API استعمال ڪري سگھجي ٿو. دستاويز اليڪٽرانڪ طور تي دستياب آهي:
REST API
Java API
انٽرپرائز سڃاڻپ فراهم ڪندڙ (آن-پريم)
صارف فيڊريشن سروسز ذريعي صارفين جي تصديق ڪرڻ جي صلاحيت.
پاس-ٿرو آٿنٽيڪيشن پڻ استعمال ٿي سگھي ٿو - جيڪڏھن استعمال ڪندڙ ڪاربروس (LDAP يا AD) سان ڪم اسٽيشنن جي خلاف تصديق ڪن ٿا، ته پوءِ اھي پاڻمرادو تصديق ڪري سگھجن ٿا Keycloak تي بغير ڪنھن پنھنجي يوزرنيم ۽ پاسورڊ داخل ڪرڻ جي.
صارفين جي تصديق ۽ وڌيڪ اجازت ڏيڻ لاء، اهو ممڪن آهي ته هڪ تعلقي DBMS استعمال ڪيو وڃي، جيڪو ترقي جي ماحول لاء تمام گهڻو لاڳو ٿئي ٿو، ڇاڪاڻ ته اهو منصوبن جي شروعاتي مرحلن ۾ ڊگهي سيٽنگون ۽ انضمام شامل نه آهي. ڊفالٽ طور، Keycloak استعمال ڪري ٿو بلٽ ان DBMS سيٽنگون ۽ صارف ڊيٽا کي ذخيرو ڪرڻ لاءِ.
سپورٽ ٿيل ڊي بي ايم ايس جي فهرست وسيع آهي ۽ ان ۾ شامل آهي: MS SQL، Oracle، PostgreSQL، MariaDB، Oracle ۽ ٻيا. هينئر تائين سڀ کان وڌيڪ آزمايل آهن Oracle 12C Release1 RAC ۽ Galera 3.12 ڪلسٽر مارڪس ڊي بي 10.1.19 لاءِ.
سڃاڻپ فراهم ڪندڙ - سماجي لاگ ان
اهو سماجي نيٽ ورڪن مان لاگ ان استعمال ڪرڻ ممڪن آهي. صارفين جي تصديق ڪرڻ جي صلاحيت کي چالو ڪرڻ لاء، استعمال ڪريو Keycloack منتظم ڪنسول. ايپليڪيشن ڪوڊ ۾ تبديلين جي ضرورت ناهي ۽ هي ڪارڪردگي دٻي کان ٻاهر موجود آهي ۽ منصوبي جي ڪنهن به مرحلي تي چالو ٿي سگهي ٿو.
اهو استعمال ڪرڻ ممڪن آهي OpenID/SAML سڃاڻپ فراهم ڪندڙ صارف جي تصديق لاءِ.
Keycloak ۾ OAuth2 استعمال ڪندي عام اختيار جا منظرنامو
اختيار ڪرڻ جو ڪوڊ فلو - استعمال ٿيل سرور-سائڊ ايپليڪيشنن سان. اختيار جي اجازت جي سڀ کان وڌيڪ عام قسمن مان هڪ آهي ڇو ته اها سرور ايپليڪيشنن لاءِ مناسب آهي جتي ايپليڪيشن جو سورس ڪوڊ ۽ ڪلائنٽ ڊيٽا ٻاهرين ماڻهن لاءِ دستياب ناهي. هن معاملي ۾ عمل redirection تي ٻڌل آهي. ايپليڪيشن کي لازمي طور تي هڪ صارف ايجنٽ (يوزر-ايجنٽ) سان رابطو ڪرڻ جي قابل هوندو، جهڙوڪ ويب برائوزر - صارف ايجنٽ ذريعي ريڊريٽ ڪيل API اختياري ڪوڊ حاصل ڪرڻ لاءِ.
جڙيل وهڪري - استعمال ٿيل موبائل يا ويب ايپليڪيشنون (ايپليڪيشنون استعمال ڪندڙ جي ڊوائيس تي هلندڙ).
نقلي اختيار جي اجازت جو قسم موبائل ۽ ويب ايپليڪيشنن پاران استعمال ڪيو ويندو آهي جتي ڪلائنٽ جي رازداري جي ضمانت نه ٿي سگھي. ضمني اجازت جو قسم پڻ استعمال ڪري ٿو يوزر ايجنٽ ريڊائريڪشن، جنهن جي ذريعي رسائي ٽوڪن کي منظور ڪيو ويو آهي صارف ايجنٽ کي ايپليڪيشن ۾ وڌيڪ استعمال لاءِ. هي ٽوڪن صارف ۽ ٻين ايپليڪيشنن کي صارف جي ڊوائيس تي دستياب بڻائي ٿو. هن قسم جي اختيار جي اجازت ايپليڪيشن جي سڃاڻپ جي تصديق نه ڪندي آهي، ۽ اهو عمل پاڻ کي ريڊريٽ URL تي ڀاڙي ٿو (اڳ ۾ خدمت سان رجسٽر ٿيل).
Implicit Flow رسائي ٽوڪن ريفريش ٽوڪن کي سپورٽ نٿو ڪري.
ڪلائنٽ سندون گرانٽ فلو - استعمال ٿيندا آهن جڏهن ايپليڪيشن API تائين رسائي ڪري ٿي. هن قسم جي اجازت جي اجازت عام طور تي استعمال ڪئي ويندي آهي سرور کان سرور جي رابطي لاءِ جيڪي پس منظر ۾ فوري طور تي صارف جي رابطي کان سواءِ ٿيڻ گهرجن. ڪلائنٽ جي سندون گرانٽ فلو هڪ ويب سروس (خفيه ڪلائنٽ) کي اجازت ڏئي ٿي ته هو پنهنجي سند استعمال ڪرڻ بجاءِ هڪ صارف جي تصديق ڪرڻ لاءِ جڏهن ٻي ويب سروس کي ڪال ڪري. سيڪيورٽي جي اعلي سطح لاء، اهو ممڪن آهي ڪالنگ سروس لاء هڪ سند استعمال ڪرڻ لاء (هڪ گڏيل راز جي بدران) هڪ سند طور.
OAuth2 وضاحت ۾ بيان ڪيو ويو آهي
JWT ٽوڪن ۽ ان جا فائدا
JWT (JSON ويب ٽوڪن) هڪ کليل معيار آهي () جيڪو JSON اعتراض جي طور تي پارٽين جي وچ ۾ معلومات کي محفوظ طور تي منتقل ڪرڻ لاء هڪ جامع ۽ خودمختار طريقو بيان ڪري ٿو.
معيار جي مطابق، ٽوڪن بنيادي-64 فارميٽ ۾ ٽن حصن تي مشتمل آهي، ڊٽس سان الڳ ٿيل. پهرين حصي کي هيڊر سڏيو ويندو آهي، جنهن ۾ ٽوڪن جو قسم ۽ ڊجيٽل دستخط حاصل ڪرڻ لاءِ هيش الگورٿم جو نالو هوندو آهي. ٻيو حصو بنيادي معلومات محفوظ ڪري ٿو (استعمال ڪندڙ، خاصيتون، وغيره). ٽيون حصو ڊجيٽل دستخط آهي.
. .
توهان جي ڊي بي ۾ هڪ ٽوڪن کي ذخيرو نه ڪريو. ڇاڪاڻ ته هڪ صحيح ٽوڪن هڪ پاس ورڊ جي برابر آهي، ٽوڪن کي محفوظ ڪرڻ جهڙو آهي پاسورڊ کي صاف متن ۾ محفوظ ڪرڻ.
رسائي ٽوڪن ھڪڙو ٽوڪن آھي جيڪو پنھنجي مالڪ کي محفوظ سرور وسيلن تائين رسائي ڏئي ٿو. اهو عام طور تي هڪ مختصر زندگي گذاريندو آهي ۽ اضافي معلومات کڻي سگھي ٿو جهڙوڪ ٽوڪن جي درخواست ڪندڙ پارٽي جو IP پتو.
ٽوڪن کي تازو ڪريو ھڪڙو ٽوڪن آھي جيڪو ڪلائنٽ کي اجازت ڏئي ٿو نيون رسائي ٽوڪن جي درخواست ڪرڻ کان پوءِ انھن جي زندگيءَ جو مدو ختم ٿي ويو آھي. اهي ٽوڪن عام طور تي ڊگهي عرصي تائين جاري ڪيا ويندا آهن.
microservice فن تعمير ۾ استعمال ڪرڻ جا بنيادي فائدا:
- ھڪڙي وقت جي تصديق جي ذريعي مختلف ايپليڪيشنن ۽ خدمتن تائين رسائي جي صلاحيت.
- صارف جي پروفائيل ۾ ڪيترن ئي گهربل خاصيتن جي غير موجودگي ۾، اهو ممڪن آهي ته ڊيٽا کي وڌايو وڃي جيڪو پيل لوڊ ۾ شامل ڪري سگهجي ٿو، بشمول خودڪار ۽ پرواز تي.
- فعال سيشن بابت معلومات کي ذخيرو ڪرڻ جي ڪا ضرورت ناهي، سرور ايپليڪيشن کي صرف دستخط جي تصديق ڪرڻ جي ضرورت آهي.
- پيل لوڊ ۾ اضافي خاصيتن ذريعي وڌيڪ لچڪدار رسائي ڪنٽرول.
- هيڊر ۽ پيل لوڊ لاءِ ٽوڪن جي نشاني جو استعمال مڪمل طور تي حل جي سيڪيورٽي کي وڌائي ٿو.
JWT ٽوڪن - ساخت
هيڊر - ڊفالٽ طور، هيڊر صرف ٽوڪن جو قسم ۽ انڪرپشن لاءِ استعمال ٿيل الگورٿم تي مشتمل آهي.
ٽوڪن جو قسم "ٽائيپ" چيڪ ۾ ذخيرو ٿيل آهي. JWT ۾ 'قسم' ڪيچ کي نظرانداز ڪيو ويو آهي. جيڪڏهن "ٽائيپ" چيڪ موجود آهي، ان جي قيمت JWT هجڻ گهرجي انهي کي ظاهر ڪرڻ لاء ته هي اعتراض هڪ JSON ويب ٽوڪن آهي.
ٻيو اهم "alg" ٽوڪن کي انڪرپٽ ڪرڻ لاءِ استعمال ٿيندڙ الگورتھم کي بيان ڪري ٿو. ان کي ڊفالٽ طور HS256 تي مقرر ڪيو وڃي. هيڊر بنيادي 64 ۾ انڪوڊ ٿيل آهي.
{ "alg": "HS256"، "قسم": "JWT"}
پيل لوڊ (مواد) - پيل لوڊ ڪنهن به معلومات کي محفوظ ڪري ٿو جنهن کي جانچڻ جي ضرورت آهي. پيل لوڊ ۾ هر هڪ کي "دعوي" طور سڃاتو وڃي ٿو. مثال طور، توهان درخواست داخل ڪري سگهو ٿا صرف دعوت ذريعي (بند ٿيل پرومو). جڏهن اسان ڪنهن کي شرڪت ڪرڻ جي دعوت ڏيڻ چاهيون ٿا، اسان انهن کي هڪ دعوت نامو موڪليندا آهيون. اهو چيڪ ڪرڻ ضروري آهي ته اي ميل ايڊريس ان شخص جو آهي جيڪو دعوت قبول ڪري ٿو، تنهنڪري اسان هن ايڊريس کي پيل لوڊ ۾ شامل ڪنداسين، ان لاءِ اسان ان کي "اي ميل" چيڪ ۾ ذخيرو ڪندا آهيون.
{ "اي ميل": "[ايميل محفوظ ٿيل]"}
پيل لوڊ ۾ ڪنجيون پاڻمرادو ٿي سگهن ٿيون. تنهن هوندي به، ڪجھ محفوظ آهن:
- iss (جاري ڪندڙ) - ايپليڪيشن کي سڃاڻي ٿو جتان ٽوڪن موڪليو پيو وڃي.
- ذيلي (موضوع) - ٽوڪن جي موضوع کي بيان ڪري ٿو.
- aud (Audience) ڪيس-حساس تارن يا URIs جو هڪ سلسلو آهي جيڪو هن ٽوڪن جي وصول ڪندڙن جي فهرست آهي. جڏهن وصول ڪندڙ طرف ڏنل چيڪ سان JWT وصول ڪري ٿي، ان کي لازمي طور تي چيڪ ڪرڻ گهرجي ته وصول ڪندڙن ۾ موجود آهي - ٻي صورت ۾ ٽوڪن کي نظر انداز ڪريو.
- exp (ختم ٿيڻ جو وقت) - اشارو ڪري ٿو جڏهن ٽوڪن ختم ٿئي ٿي. JWT معيار کي ختم ٿيل ٽوڪن کي رد ڪرڻ لاءِ ان جي سڀني عملن جي ضرورت آهي. Exp key کي يونڪس فارميٽ ۾ ٽائم اسٽيمپ هجڻ گھرجي.
- nbf (اڳ ۾ نه) هڪ وقت آهي يونڪس فارميٽ ۾ جيڪو اهو لمحو طئي ڪري ٿو جڏهن ٽوڪن صحيح ٿي وڃي ٿي.
- iat (جاري ڪيل ايٽ) - هي ڪيٽي نمائندگي ڪري ٿو وقت جو ٽوڪن جاري ڪيو ويو ۽ استعمال ڪري سگهجي ٿو JWT جي عمر کي طئي ڪرڻ لاءِ. iat ڪيئي يونڪس فارميٽ ۾ ٽائم اسٽيمپ هجڻ گھرجي.
- Jti (JWT ID) - هڪ اسٽرنگ جيڪو وضاحت ڪري ٿو منفرد سڃاڻپ ڪندڙ هن ٽوڪن جي، ڪيس-حساس.
اهو سمجهڻ ضروري آهي ته پيلوڊ انڪرپٽ ٿيل فارم ۾ منتقل نه ڪيو ويو آهي (جيتوڻيڪ ٽوڪن کي اينسٽ ڪري سگهجي ٿو ۽ ان کان پوء انڪريپٽ ٿيل ڊيٽا کي منتقل ڪرڻ ممڪن آهي). تنهن ڪري، اهو ڪنهن به ڳجهي معلومات کي ذخيرو نٿو ڪري سگهي. هيڊر وانگر، پيل لوڊ بيس 64 انڪوڊ ٿيل آهي.
صحيح - هڪ دفعو اسان وٽ هيڊر ۽ پيل لوڊ آهي، اسان دستخط جي حساب ڪري سگهون ٿا.
بيس 64-انڪوڊ ٿيل: هيڊر ۽ پيل لوڊ ورتو وڃي ٿو، اهي هڪ ڊٽ ذريعي هڪ تار ۾ گڏيل آهن. پوءِ هي اسٽرنگ ۽ ڳجهي ڪيئي هيڊر ("alg" ڪيئي) ۾ بيان ڪيل انڪرپشن الگورٿم ۾ داخل ٿيل آهن. ڪنجي ڪنهن به تار ٿي سگهي ٿو. ڊگھي تارن کي وڌيڪ ترجيح ڏني ويندي ڇو ته ان کي کڻڻ ۾ وڌيڪ وقت لڳندو.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
تعمير ڪرڻ هڪ Keycloak ناڪامي ڪلستر آرڪيٽيڪچر
جڏهن سڀني منصوبن لاءِ هڪ واحد ڪلستر استعمال ڪيو وڃي، اتي هڪ SSO حل لاءِ گهرجون وڌيون آهن. جڏهن منصوبن جو تعداد ننڍڙو آهي، اهي گهرجون سڀني منصوبن لاء ايترو قابل ذڪر نه آهن، جڏهن ته، صارفين ۽ انضمام جي تعداد ۾ اضافو سان، دستيابي ۽ ڪارڪردگي جي ضرورتن ۾ اضافو ٿيندو.
سنگل ايس ايس او جي ناڪامي جي خطري کي وڌائڻ سان حل جي فن تعمير جي ضرورتن کي وڌائي ٿو ۽ غير ضروري اجزاء لاء استعمال ڪيل طريقن ۽ هڪ تمام سخت SLA ڏانهن وڌي ٿو. ان سلسلي ۾، گهڻو ڪري ترقي يا حل لاڳو ڪرڻ جي شروعاتي مرحلن دوران، منصوبن وٽ پنهنجون غير غلطي برداشت ڪرڻ وارو انفراسٽرڪچر هوندو آهي. جيئن ترقي ٿيندي آهي، تيئن ترقي ۽ اسڪيلنگ جا موقعا ترتيب ڏيڻ گهرجن. ڪنٽينر ورچوئلائيزيشن يا هائبرڊ اپروچ استعمال ڪندي هڪ ناڪامي ڪلستر ٺاهڻ لاءِ اهو سڀ کان وڌيڪ لچڪدار آهي.
فعال/فعال ۽ فعال/غير فعال ڪلسٽر موڊس ۾ ڪم ڪرڻ لاءِ، ضروري آهي ته ڊيٽا جي مطابقت کي يقيني بڻائڻ لاءِ هڪ تعلقي ڊيٽابيس ۾- ٻنهي ڊيٽابيس نوڊس کي لازمي طور تي مختلف جيو ورهايل ڊيٽا سينٽرن جي وچ ۾ هم وقت سازي ڪرڻ گهرجي.
غلطي برداشت ڪرڻ واري تنصيب جو آسان مثال.
ھڪڙو ڪلستر استعمال ڪرڻ جا فائدا ڇا آھن:
- اعلي دستيابي ۽ ڪارڪردگي.
- آپريٽنگ موڊس لاءِ سپورٽ: فعال / فعال، فعال / غير فعال.
- متحرڪ طور تي ماپ ڪرڻ جي صلاحيت - جڏهن ڪنٽينر ورچوئلائيزيشن استعمال ڪندي.
- مرڪزي انتظام ۽ نگراني جو امڪان.
- پروجيڪٽ ۾ استعمال ڪندڙن جي سڃاڻپ/تصديق/ اختيار ڏيڻ لاءِ متحد طريقو.
- صارف جي شموليت کان سواء مختلف منصوبن جي وچ ۾ وڌيڪ شفاف رابطي.
- مختلف منصوبن ۾ JWT ٽوڪن کي ٻيهر استعمال ڪرڻ جي صلاحيت.
- اعتماد جو واحد نقطو.
- مائڪرو سروسز / ڪنٽينر ورچوئلائيزيشن استعمال ڪندي منصوبن جو تيز لانچ (اضافي اجزاء کڻڻ ۽ ترتيب ڏيڻ جي ضرورت ناهي).
- اهو ممڪن آهي ته وڪرو ڪندڙ کان تجارتي مدد خريد ڪرڻ.
ڪلستر جي منصوبابندي ڪرڻ وقت ڇا ڏسڻ گهرجي
ڊي بي ايم ايس
Keycloak ذخيرو ڪرڻ لاء ڊيٽابيس مينيجمينٽ سسٽم استعمال ڪري ٿو: حقيقي، ڪلائنٽ، استعمال ڪندڙ، وغيره.
DBMS جي هڪ وسيع رينج جي حمايت ڪئي وئي آهي: MS SQL، Oracle، MySQL، PostgreSQL. Keycloak اچي ٿو ان جي پنهنجي تعمير ٿيل تعلقي ڊيٽابيس سان. اهو غير لوڊ ٿيل ماحول لاء استعمال ڪرڻ جي سفارش ڪئي وئي آهي - جهڙوڪ ترقياتي ماحول.
فعال/فعال ۽ فعال/غير فعال ڪلسٽر موڊس ۾ ڪم ڪرڻ لاءِ، هڪ تعلقي ڊيٽابيس ۾ ڊيٽا جي تسلسل جي ضرورت آهي، ۽ ٻنهي ڊيٽابيس ڪلسٽر نوڊس کي هم وقت سازي سان ڊيٽا سينٽرن جي وچ ۾ نقل ڪيو ويو آهي.
ورهايل ڪيش (Infinspan)
ڪلستر لاءِ صحيح ڪم ڪرڻ لاءِ، JBoss ڊيٽا گرڊ استعمال ڪندي هيٺين قسمن جي ڪيچ جي اضافي هم وقت سازي جي ضرورت آهي:
تصديق سيشن - ڊيٽا کي بچائڻ لاء استعمال ڪيو ويو جڏهن هڪ مخصوص صارف جي تصديق ڪري ٿي. هن ڪيش مان درخواستون عام طور تي صرف برائوزر ۽ Keycloak سرور شامل آهن، ايپليڪيشن نه.
ايڪشن ٽوڪن منظرنامن لاءِ استعمال ڪيا ويندا آهن جتي صارف کي لازمي طور تي عمل جي تصديق ڪرڻ جي ضرورت آهي (اي ميل ذريعي). مثال طور، پاسورڊ وساري ويهڻ دوران، ايڪشن ٽوڪن انفني اسپن ڪيش استعمال ڪيو ويندو آهي ميٽا ڊيٽا جي ٽريڪ رکڻ لاءِ لاڳاپيل ايڪشن ٽوڪن بابت جيڪي اڳ ۾ ئي استعمال ڪيا ويا آهن، تنهنڪري ان کي ٻيهر استعمال نٿو ڪري سگهجي.
مسلسل ڊيٽا جي ڪيشنگ ۽ غلط ڪرڻ - مسلسل ڊيٽا کي ڪيش ڪرڻ لاء استعمال ڪيو ويو ته ڊيٽابيس ۾ غير ضروري سوالن کان بچڻ لاء. جڏهن ڪو به Keycloak سرور ڊيٽا کي اپڊيٽ ڪري ٿو، سڀني ڊيٽا سينٽرن ۾ ٻين سڀني Keycloak سرورز کي ان بابت ڄاڻڻ جي ضرورت آهي.
ڪم - صرف ڪلستر نوڊس ۽ ڊيٽا سينٽرن جي وچ ۾ غلط پيغام موڪلڻ لاءِ استعمال ڪيو ويو.
استعمال ڪندڙ سيشن - استعمال ڪندڙ سيشن بابت ڊيٽا کي ذخيرو ڪرڻ لاء استعمال ڪيو ويو جيڪي صارف جي برائوزر سيشن جي مدت لاء صحيح آهن. ڪيش کي آخري صارف ۽ ايپليڪيشن کان HTTP درخواستن کي سنڀالڻ گهرجي.
برٽ فورس تحفظ - ناڪام لاگ ان بابت ڊيٽا کي ٽريڪ ڪرڻ لاء استعمال ڪيو ويو.
لوڊ توازن
لوڊ بيلنسر ڪيڪلوڪ ڏانهن واحد داخلا نقطو آهي ۽ چپچپا سيشن کي سپورٽ ڪرڻ گهرجي.
ايپليڪيشن سرورز
اهي هڪ ٻئي سان اجزاء جي رابطي کي ڪنٽرول ڪرڻ لاءِ استعمال ڪيا ويندا آهن ۽ موجوده آٽوميشن اوزار ۽ انفراسٽرڪچر آٽوميشن اوزار جي متحرڪ اسڪيلنگ استعمال ڪندي ورچوئل يا ڪنٽينرائيز ٿي سگهن ٿا. OpenShift، Kubernates، Rancher ۾ سڀ کان وڌيڪ عام تعيناتي منظرنامو.
اهو پهريون حصو ختم ڪري ٿو - نظرياتي هڪ. مضمونن جي ايندڙ سيريز ۾، مختلف سڃاڻپ فراهم ڪندڙن سان انضمام جا مثال ۽ سيٽنگن جي مثالن جو تجزيو ڪيو ويندو.
جو ذريعو: www.habr.com