کسی بھی بڑی کمپنی، اور X5 ریٹیل گروپ میں کوئی رعایت نہیں ہے، جیسے جیسے ترقی ہوتی ہے، ایسے منصوبوں کی تعداد بڑھ جاتی ہے جن کے لیے صارف کی اجازت درکار ہوتی ہے۔ وقت گزرنے کے ساتھ، صارفین کی ایک ایپلیکیشن سے دوسری ایپلیکیشن میں بغیر کسی رکاوٹ کی منتقلی کی ضرورت ہوتی ہے اور پھر ایک سنگل سنگل آن (SSO) سرور استعمال کرنے کی ضرورت ہوتی ہے۔ لیکن کیا کریں جب شناخت فراہم کرنے والے جیسے کہ AD یا دیگر جن میں اضافی خصوصیات نہیں ہیں پہلے سے ہی مختلف پروجیکٹس میں استعمال کیے جاتے ہیں۔ "شناختی بروکرز" کہلانے والے نظاموں کی ایک کلاس بچاؤ کے لیے آئے گی۔ سب سے زیادہ فعال اس کے نمائندے ہیں، جیسے کی کلوک، گریویٹی ایکسیس مینجمنٹ وغیرہ۔ اکثر، استعمال کے منظرنامے مختلف ہو سکتے ہیں: مشین کا تعامل، صارف کی شرکت، وغیرہ۔ اور اس طرح کا حل ہماری کمپنی کے پاس اب ایک اشارے بروکر ہے - کی کلوک۔
Keycloak ایک اوپن سورس شناخت اور رسائی کنٹرول پروڈکٹ ہے جسے RedHat کے ذریعے برقرار رکھا جاتا ہے۔ یہ SSO - RH-SSO استعمال کرنے والی کمپنی کی مصنوعات کی بنیاد ہے۔
بنیادی تصورات
اس سے پہلے کہ آپ حل اور نقطہ نظر کو سمجھنا شروع کریں، آپ کو عمل کی شرائط اور ترتیب کی وضاحت کرنی چاہیے:
شناخت۔ کسی موضوع کو اس کے شناخت کنندہ کے ذریعے پہچاننے کا طریقہ کار ہے (دوسرے لفظوں میں، یہ نام، لاگ ان یا نمبر کا تعین کر رہا ہے)۔
توثیق - یہ ایک توثیق کا طریقہ کار ہے (صارف کی تصدیق پاس ورڈ کے ذریعے کی جاتی ہے، خط کی تصدیق الیکٹرانک دستخط وغیرہ کے ذریعے کی جاتی ہے۔)
اجازت - وسائل تک رسائی فراہم کر رہا ہے (مثال کے طور پر، ای میل)۔
کی کلوک شناختی بروکر
چابی کی چادر ایک اوپن سورس شناخت اور رسائی کے انتظام کا حل ہے جو IS میں استعمال کے لیے ڈیزائن کیا گیا ہے جہاں مائیکرو سروس آرکیٹیکچر پیٹرن استعمال کیے جا سکتے ہیں۔
Keycloak سنگل سائن آن (SSO)، بروکرڈ آئیڈینٹیٹی اور سوشل لاگ ان، یوزر فیڈریشن، کلائنٹ اڈاپٹر، ایڈمن کنسول، اور اکاؤنٹ مینجمنٹ کنسول جیسی خصوصیات پیش کرتا ہے۔
کیکلوک میں بنیادی فعالیت کی حمایت کی گئی ہے:
- براؤزر ایپلیکیشنز کے لیے سنگل سائن آن اور سنگل سائن آؤٹ۔
- OpenID/OAuth 2.0/SAML سپورٹ۔
- شناختی بروکرنگ - بیرونی اوپن آئی ڈی کنیکٹ یا SAML شناخت فراہم کنندگان کا استعمال کرتے ہوئے تصدیق۔
- سوشل لاگ ان - صارف کی شناخت کے لیے گوگل، گٹ ہب، فیس بک، ٹویٹر کے لیے سپورٹ۔
- یوزر فیڈریشن - LDAP اور ایکٹو ڈائرکٹری سرورز اور دیگر شناختی فراہم کنندگان سے صارفین کی ہم آہنگی۔
- Kerberos bridge - خودکار صارف کی تصدیق کے لیے Kerberos سرور کا استعمال۔
- ایڈمن کنسول - ویب کے ذریعے ترتیبات اور حل کے پیرامیٹرز کے متحد انتظام کے لیے۔
- اکاؤنٹ مینجمنٹ کنسول - آزاد صارف پروفائل مینجمنٹ کے لیے۔
- کمپنی کی کارپوریٹ شناخت کی بنیاد پر حل کی تخصیص۔
- 2FA توثیق - TOTP/HOTP Google Authenticator یا FreeOTP کا استعمال کرتے ہوئے سپورٹ۔
- لاگ ان فلوز - صارف کی خود رجسٹریشن، پاس ورڈ کی بازیافت اور دوبارہ ترتیب دینا، اور دیگر ممکن ہیں۔
- سیشن مینجمنٹ - منتظمین ایک نقطہ سے صارف کے سیشن کا انتظام کرسکتے ہیں۔
- ٹوکن میپرز - ٹوکنز میں صارف کی صفات، کردار اور دیگر مطلوبہ صفات کا پابند ہونا۔
- دائرے، ایپلیکیشن اور صارفین کے ذریعے لچکدار پالیسی مینجمنٹ۔
- CORS سپورٹ - کلائنٹ اڈاپٹر کو مقامی CORS سپورٹ حاصل ہے۔
- سروس پرووائیڈر انٹرفیسز (SPI) – SPIs کی ایک بڑی تعداد جو آپ کو سرور کے مختلف پہلوؤں کو ترتیب دینے کی اجازت دیتی ہے: توثیق کا بہاؤ، شناخت فراہم کرنے والے، پروٹوکول میپنگ اور بہت کچھ۔
- JavaScript ایپلی کیشنز، WildFly، JBoss EAP، Fuse، Tomcat، Jetty، Spring کے لیے کلائنٹ اڈاپٹر۔
- اوپن آئی ڈی کنیکٹ ریلینگ پارٹی لائبریری یا SAML 2.0 سروس پرووائیڈر لائبریری کو سپورٹ کرنے والی مختلف ایپلی کیشنز کے ساتھ کام کرنے کے لیے تعاون۔
- پلگ ان کا استعمال کرتے ہوئے قابل توسیع۔
CI/CD پراسیسز کے ساتھ ساتھ Keycloak میں انتظامی عمل کے آٹومیشن کے لیے REST API/JAVA API استعمال کیا جا سکتا ہے۔ دستاویزات الیکٹرانک شکل میں دستیاب ہیں:
باقی API
JAVA API
انٹرپرائز شناخت فراہم کرنے والے (آن پریمائز)
صارف فیڈریشن کی خدمات کے ذریعے صارف کی تصدیق کا امکان۔
پاس تھرو توثیق کا استعمال بھی کیا جا سکتا ہے - اگر صارفین کی کربروس (LDAP یا AD) کے ساتھ ورک سٹیشن پر تصدیق کی جاتی ہے، تو وہ اپنا صارف نام اور پاس ورڈ دوبارہ فراہم کیے بغیر خود بخود Keycloak پر تصدیق کر سکتے ہیں۔
صارفین کی تصدیق اور مزید اجازت کے لیے، متعلقہ ڈی بی ایم ایس کا استعمال ممکن ہے، جو ترقیاتی ماحول کے لیے سب سے زیادہ لاگو ہوتا ہے، کیونکہ اس میں پراجیکٹس کے ابتدائی مراحل میں لمبی سیٹنگز اور انضمام کی ضرورت نہیں ہے۔ پہلے سے طے شدہ طور پر، Keycloak ترتیبات اور صارف کے ڈیٹا کو ذخیرہ کرنے کے لیے بلٹ ان DBMS استعمال کرتا ہے۔
تعاون یافتہ DBMSs کی فہرست وسیع ہے اور اس میں شامل ہیں: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle اور دیگر۔ اس وقت سب سے زیادہ آزمائے گئے ماریا ڈی بی 12 کے لیے Oracle 1C Release3.12 RAC اور Galera 10.1.19 کلسٹر ہیں۔
شناخت فراہم کرنے والے - سماجی لاگ ان
سوشل نیٹ ورکس سے لاگ ان استعمال کرنا ممکن ہے۔ صارفین کی توثیق کرنے کی اہلیت کو فعال کرنے کے لیے، Keycloack ایڈمن کنسول استعمال کریں۔ ایپلیکیشن کوڈ میں کسی تبدیلی کی ضرورت نہیں ہے اور یہ فعالیت باکس کے باہر دستیاب ہے اور پروجیکٹ کے کسی بھی مرحلے پر اسے چالو کیا جا سکتا ہے۔
صارفین کی توثیق کرنے کے لیے، OpenID/SAML شناختی فراہم کنندگان کا استعمال ممکن ہے۔
کیکلوک میں OAuth2 کا استعمال کرتے ہوئے عام اجازت کے منظرنامے۔
اجازت کوڈ کا بہاؤ - سرور سائیڈ ایپلی کیشنز کے ساتھ استعمال کیا جاتا ہے۔ اجازت کی اجازت کی سب سے عام اقسام میں سے ایک کیونکہ یہ سرور سائیڈ ایپلی کیشنز کے لیے موزوں ہے جہاں ایپلیکیشن کا سورس کوڈ اور کلائنٹ ڈیٹا دوسروں کے لیے قابل رسائی نہیں ہے۔ اس معاملے میں عمل ری ڈائریکشن پر مبنی ہے۔ ایپلیکیشن کو صارف ایجنٹ (صارف-ایجنٹ) کے ساتھ بات چیت کرنے کے قابل ہونا چاہیے، جیسے کہ ویب براؤزر، صارف کے ایجنٹ کے ذریعے آگے بھیجے گئے API کی اجازت کے کوڈز حاصل کرنے کے لیے۔
مضمر بہاؤ - موبائل یا ویب ایپلیکیشنز کے ذریعہ استعمال کیا جاتا ہے (صارف کے آلے پر چلنے والی ایپلی کیشنز)۔
مضمر اجازت کی قسم موبائل اور ویب ایپلیکیشنز کے ذریعہ استعمال کی جاتی ہے جہاں کلائنٹ کی رازداری کی ضمانت نہیں دی جاسکتی ہے۔ مضمر اجازت کی قسم صارف ایجنٹ کی ری ڈائریکشن کا بھی استعمال کرتی ہے، جہاں ایپلیکیشن میں بعد میں استعمال کے لیے رسائی ٹوکن صارف ایجنٹ کو بھیج دیا جاتا ہے۔ اس سے صارف کے آلے پر ٹوکن اور دیگر ایپلیکیشنز کو ٹوکن دستیاب ہو جاتا ہے۔ اس قسم کی اجازت سے درخواست کی شناخت کی توثیق نہیں ہوتی، اور یہ عمل خود ری ڈائریکٹ URL پر انحصار کرتا ہے (پہلے سروس کے ساتھ رجسٹرڈ)۔
امپلیسیٹ فلو رسائی ٹوکن ریفریش ٹوکنز کو سپورٹ نہیں کرتا ہے۔
کلائنٹ کی اسناد گرانٹ فلو - استعمال کیا جاتا ہے جب ایپلیکیشن API تک رسائی حاصل کرتی ہے۔ اس قسم کی اجازت نامہ عام طور پر سرور سے سرور تک تعاملات کے لیے استعمال ہوتا ہے جو فوری صارف کے تعامل کے بغیر پس منظر میں ہونا چاہیے۔ کلائنٹ کی اسنادی گرانٹ کا بہاؤ کسی ویب سروس (خفیہ کلائنٹ) کو اجازت دیتا ہے کہ وہ کسی اور ویب سروس کو کال کرتے وقت تصدیق کے لیے صارف کی نقالی کرنے کے بجائے اس کی اپنی اسناد استعمال کرے۔ سیکیورٹی کے اعلیٰ درجے کے لیے، کالنگ سروس کے لیے یہ ممکن ہے کہ وہ سرٹیفکیٹ (مشترکہ راز کی بجائے) بطور اسناد استعمال کرے۔
OAuth2 تفصیلات میں بیان کیا گیا ہے۔
JWT ٹوکن اور اس کے فوائد
JWT (JSON ویب ٹوکن) ایک کھلا معیار ہے ()، جو JSON آبجیکٹ کی شکل میں فریقین کے درمیان معلومات کو محفوظ طریقے سے منتقل کرنے کے لیے ایک کمپیکٹ اور خود ساختہ طریقہ کی وضاحت کرتا ہے۔
معیار کے مطابق، ایک ٹوکن بیس-64 فارمیٹ میں تین حصوں پر مشتمل ہوتا ہے، جو نقطوں سے الگ ہوتے ہیں۔ پہلے حصے کو ہیڈر کہا جاتا ہے جس میں ڈیجیٹل دستخط حاصل کرنے کے لیے ٹوکن کی قسم اور ہیش الگورتھم کا نام ہوتا ہے۔ دوسرا حصہ بنیادی معلومات (صارف، صفات وغیرہ) کو محفوظ کرتا ہے۔ تیسرا حصہ ڈیجیٹل دستخط ہے۔
. .
اپنے ڈیٹا بیس میں ٹوکن کو کبھی بھی ذخیرہ نہ کریں۔ چونکہ ایک درست ٹوکن پاس ورڈ کے مترادف ہے، اس لیے ٹوکن کو ذخیرہ کرنا بالکل واضح متن میں پاس ورڈ ذخیرہ کرنے کے مترادف ہے۔
رسائی ٹوکن ایک ٹوکن ہے جو اس کے مالک کو محفوظ سرور وسائل تک رسائی فراہم کرتا ہے۔ اس کی عام طور پر زندگی مختصر ہوتی ہے اور اس میں اضافی معلومات ہو سکتی ہیں، جیسے کہ ٹوکن کی درخواست کرنے والی پارٹی کا IP پتہ۔
ٹوکن ریفریش کریں۔ ایک ٹوکن ہے جو کلائنٹس کو ان کی زندگی بھر کے ختم ہونے کے بعد نئے رسائی ٹوکن کی درخواست کرنے کی اجازت دیتا ہے۔ یہ ٹوکن عام طور پر طویل مدت کے لیے جاری کیے جاتے ہیں۔
مائیکرو سروس فن تعمیر کے استعمال کے اہم فوائد:
- ایک بار کی تصدیق کے ذریعے مختلف ایپلی کیشنز اور خدمات تک رسائی حاصل کرنے کی اہلیت۔
- صارف کے پروفائل میں متعدد مطلوبہ صفات کی عدم موجودگی میں، ان کو ڈیٹا کے ساتھ افزودہ کرنا ممکن ہے جسے پے لوڈ میں شامل کیا جا سکتا ہے، بشمول خود کار طریقے سے اور پرواز پر۔
- فعال سیشن کے بارے میں معلومات کو ذخیرہ کرنے کی ضرورت نہیں ہے؛ سرور ایپلیکیشن کو صرف دستخط کی تصدیق کرنے کی ضرورت ہے۔
- پے لوڈ میں اضافی صفات کے ذریعے زیادہ لچکدار رسائی کنٹرول۔
- ہیڈر اور پے لوڈ کے لیے ٹوکن دستخط کا استعمال مجموعی حل کی حفاظت کو بڑھاتا ہے۔
JWT ٹوکن - ساخت
عنوان - پہلے سے طے شدہ طور پر، ہیڈر میں صرف ٹوکن کی قسم اور انکرپشن کے لیے استعمال ہونے والا الگورتھم ہوتا ہے۔
ٹوکن کی قسم "ٹائپ" کلید میں محفوظ ہے۔ JWT میں "ٹائپ" کلید کو نظر انداز کر دیا گیا ہے۔ اگر "ٹائپ" کلید موجود ہے تو اس کی قدر JWT ہونی چاہیے تاکہ یہ ظاہر کیا جا سکے کہ یہ آبجیکٹ JSON ویب ٹوکن ہے۔
دوسری کلید "alg" ٹوکن کو خفیہ کرنے کے لیے استعمال ہونے والے الگورتھم کی وضاحت کرتی ہے۔ پہلے سے طے شدہ طور پر اسے HS256 پر سیٹ کیا جانا چاہیے۔ ہیڈر کو بیس 64 میں انکوڈ کیا گیا ہے۔
{ "alg": "HS256", "typ": "JWT"}
پے لوڈ (مواد) - پے لوڈ کسی بھی معلومات کو ذخیرہ کرتا ہے جس کی تصدیق کرنے کی ضرورت ہے۔ پے لوڈ میں ہر کلید کو "بیان" کے نام سے جانا جاتا ہے۔ مثال کے طور پر، آپ صرف دعوت نامے (بند پروموشن) کے ذریعے درخواست داخل کر سکتے ہیں۔ جب ہم کسی کو شرکت کے لیے مدعو کرنا چاہتے ہیں، تو ہم انہیں ایک دعوتی ای میل بھیجتے ہیں۔ اس بات کی تصدیق کرنا ضروری ہے کہ ای میل ایڈریس دعوت نامہ قبول کرنے والے شخص کا ہے، لہذا ہم اس ایڈریس کو "ای میل" کلید میں اسٹور کرکے پے لوڈ میں شامل کریں گے۔
{ "ای میل": "[ای میل محفوظ]" }
پے لوڈ میں چابیاں من مانی ہو سکتی ہیں۔ تاہم، کچھ محفوظ ہیں:
- iss (جاری کنندہ) - اس درخواست کا تعین کرتا ہے جس سے ٹوکن بھیجا جاتا ہے۔
- ذیلی (موضوع) - ٹوکن کے موضوع کی وضاحت کرتا ہے۔
- aud (Audience) – کیس حساس تاروں یا URIs کی ایک صف جو اس ٹوکن کے وصول کنندگان کی فہرست ہے۔ جب وصول کنندہ پارٹی کو دی گئی کلید کے ساتھ JWT موصول ہوتا ہے، تو اسے وصول کنندگان میں خود کو چیک کرنا چاہیے - بصورت دیگر ٹوکن کو نظر انداز کر دیں۔
- exp (میعاد ختم ہونے کا وقت) - اشارہ کرتا ہے کہ ٹوکن کب ختم ہوتا ہے۔ JWT معیار کا تقاضہ ہے کہ تمام نفاذات میعاد ختم ہونے والے ٹوکن کو مسترد کریں۔ Exp کلید یونکس فارمیٹ میں ٹائم اسٹیمپ ہونی چاہیے۔
- nbf (پہلے نہیں) یونکس فارمیٹ میں ایک وقت ہے جو اس لمحے کا تعین کرتا ہے جب ٹوکن درست ہو جاتا ہے۔
- iat (جاری ہونے پر) - یہ کلید اس وقت کی نمائندگی کرتی ہے جب ٹوکن جاری کیا گیا تھا اور اسے JWT کی عمر کا تعین کرنے کے لیے استعمال کیا جا سکتا ہے۔ iat کلید یونکس فارمیٹ میں ٹائم اسٹیمپ ہونی چاہیے۔
- Jti (JWT ID) ایک سٹرنگ ہے جو اس ٹوکن کے لیے ایک منفرد کیس حساس شناخت کنندہ کی وضاحت کرتی ہے۔
یہ سمجھنا ضروری ہے کہ پے لوڈ کو انکرپٹڈ منتقل نہیں کیا جاتا ہے (حالانکہ ٹوکن کو نیسٹ کیا جا سکتا ہے اور پھر انکرپٹڈ ڈیٹا کو منتقل کرنا ممکن ہے)۔ اس لیے آپ اس میں کوئی خفیہ معلومات محفوظ نہیں کر سکتے۔ ہیڈر کی طرح، پے لوڈ بیس 64 انکوڈ ہے۔
کے دستخط - ایک بار جب ہمارے پاس ہیڈر اور پے لوڈ ہو جائے تو ہم دستخط کا حساب لگا سکتے ہیں۔
بیس 64 میں انکوڈ کردہ ہیڈر اور پے لوڈ کو ایک نقطے سے الگ کی گئی لائن میں لے جا کر ملایا جاتا ہے۔ اس سٹرنگ اور خفیہ کلید کو پھر ہیڈر میں مخصوص کردہ انکرپشن الگورتھم میں داخل کیا جاتا ہے (کلید "الگ")۔ کلید کوئی بھی تار ہو سکتی ہے۔ لمبی تاریں سب سے بہتر ہوں گی کیونکہ انہیں منتخب کرنے میں زیادہ وقت درکار ہوگا۔
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
کیکلوک فیل اوور کلسٹر آرکیٹیکچر بنانا
تمام پروجیکٹس کے لیے ایک کلسٹر استعمال کرتے وقت، SSO حل کے لیے اضافی تقاضے ہوتے ہیں۔ جب پروجیکٹس کی تعداد کم ہوتی ہے، تو یہ تقاضے تمام پروجیکٹس کے لیے اتنے اہم نہیں ہوتے، تاہم، جیسے جیسے صارفین کی تعداد اور انضمام میں اضافہ ہوتا ہے، دستیابی اور کارکردگی کے تقاضے بڑھتے ہیں۔
کسی ایک SSO کی ناکامی کے بڑھتے ہوئے خطرات حل کے فن تعمیر کے تقاضوں اور اجزاء کے بے کار ہونے کے لیے استعمال کیے جانے والے طریقوں کو بڑھاتے ہیں اور بہت سخت SLA کی طرف لے جاتے ہیں۔ اس سلسلے میں، زیادہ تر ترقی یا حل کو نافذ کرنے کے ابتدائی مراحل کے دوران، منصوبوں کا اپنا غیر غلطی برداشت کرنے والا بنیادی ڈھانچہ ہوتا ہے۔ جیسے جیسے ترقی ہوتی ہے، ترقی اور اسکیلنگ کے مواقع پیدا کرنے کی ضرورت ہوتی ہے۔ فیل اوور کلسٹر بنانے کا سب سے لچکدار طریقہ کنٹینر ورچوئلائزیشن یا ہائبرڈ اپروچ استعمال کرنا ہے۔
فعال/فعال اور فعال/غیر فعال کلسٹر طریقوں میں کام کرنے کے لیے، متعلقہ ڈیٹا بیس میں ڈیٹا کی مستقل مزاجی کو یقینی بنانا ضروری ہے - دونوں ڈیٹا بیس نوڈس کو مختلف جیو ڈسٹری بیوٹڈ ڈیٹا سینٹرز کے درمیان ہم وقت سازی سے نقل کیا جانا چاہیے۔
غلطی برداشت کرنے والی تنصیب کی آسان ترین مثال۔
سنگل کلسٹر استعمال کرنے کے کیا فوائد ہیں:
- اعلی دستیابی اور کارکردگی۔
- آپریٹنگ طریقوں کو سپورٹ کریں: فعال/فعال، فعال/غیر فعال۔
- متحرک اسکیلنگ کا امکان - کنٹینر ورچوئلائزیشن کا استعمال کرتے وقت۔
- مرکزی انتظام اور نگرانی کا امکان۔
- پراجیکٹس میں صارفین کی شناخت/توثیق/مجاز کے لیے ایک متفقہ طریقہ۔
- صارف کی بات چیت کے بغیر مختلف منصوبوں کے درمیان زیادہ شفاف تعامل۔
- مختلف منصوبوں میں JWT ٹوکن کو دوبارہ استعمال کرنے کا امکان۔
- اعتماد کا واحد نقطہ۔
- مائیکرو سروسز/کنٹینر ورچوئلائزیشن کا استعمال کرتے ہوئے پراجیکٹس کا تیزی سے آغاز (اضافی اجزاء کو انسٹال اور کنفیگر کرنے کی ضرورت نہیں)۔
- وینڈر سے تجارتی مدد خریدنا ممکن ہے۔
کلسٹر کی منصوبہ بندی کرتے وقت کن چیزوں پر غور کرنا چاہیے۔
ڈی بی ایم ایس
Keycloak محفوظ کرنے کے لیے DBMS مینجمنٹ سسٹم استعمال کرتا ہے: دائرے، کلائنٹس، صارفین، وغیرہ۔
DBMSs کی ایک وسیع رینج کی حمایت کی جاتی ہے: MS SQL، Oracle، MySQL، PostgreSQL۔ Keycloak اپنے بلٹ میں متعلقہ ڈیٹا بیس کے ساتھ آتا ہے۔ لائٹ ڈیوٹی والے ماحول میں استعمال کے لیے تجویز کردہ، جیسے ترقیاتی ماحول۔
فعال/فعال اور فعال/غیر فعال کلسٹر طریقوں میں کام کرنے کے لیے، متعلقہ ڈیٹا بیس میں ڈیٹا کی مستقل مزاجی کو یقینی بنانا ضروری ہے اور ڈیٹا بیس کلسٹر کے دونوں نوڈس کو ڈیٹا سینٹرز کے درمیان ہم آہنگی کے ساتھ نقل کیا جاتا ہے۔
تقسیم شدہ کیش (Infinspan)
کلسٹر کے درست طریقے سے کام کرنے کے لیے، JBoss ڈیٹا گرڈ کا استعمال کرتے ہوئے درج ذیل کیشے کی اقسام کی اضافی مطابقت پذیری کی ضرورت ہے۔
تصدیقی سیشنز - کسی مخصوص صارف کی توثیق کرتے وقت ڈیٹا کو بچانے کے لیے استعمال کیا جاتا ہے۔ اس کیش سے درخواستوں میں عام طور پر صرف براؤزر اور کی کلوک سرور شامل ہوتا ہے، ایپلیکیشن نہیں۔
ایکشن ٹوکنز - ایسے منظرناموں کے لیے استعمال کیا جاتا ہے جہاں صارف کو غیر مطابقت پذیر طور پر (ای میل کے ذریعے) کسی کارروائی کی تصدیق کرنے کی ضرورت ہوتی ہے۔ مثال کے طور پر، پاس ورڈ بھول جانے کے دوران، Infinispan ایکشن ٹوکنز کیشے کا استعمال متعلقہ ایکشن ٹوکنز کے بارے میں میٹا ڈیٹا پر نظر رکھنے کے لیے کیا جاتا ہے جو پہلے ہی استعمال ہو چکے ہیں، اس لیے اسے دوبارہ استعمال نہیں کیا جا سکتا۔
مستقل ڈیٹا کی کیشنگ اور باطل کرنا - ڈیٹا بیس میں غیر ضروری سوالات سے بچنے کے لیے مستقل ڈیٹا کو کیش کرنے کے لیے استعمال کیا جاتا ہے۔ جب کوئی کیکلوک سرور ڈیٹا کو اپ ڈیٹ کرتا ہے، تو تمام ڈیٹا سینٹرز میں موجود دیگر تمام کیکلوک سرورز کو اس کے بارے میں جاننا چاہیے۔
کام - صرف کلسٹر نوڈس اور ڈیٹا سینٹرز کے درمیان باطل پیغامات بھیجنے کے لیے استعمال کیا جاتا ہے۔
صارف کے سیشنز - صارف کے سیشن ڈیٹا کو ذخیرہ کرنے کے لیے استعمال کیا جاتا ہے جو صارف کے براؤزر سیشن کی مدت کے لیے درست ہے۔ کیشے کو حتمی صارف اور ایپلیکیشن سے HTTP درخواستوں کو ہینڈل کرنا چاہئے۔
بروٹ فورس پروٹیکشن - ناکام لاگ ان کے بارے میں ڈیٹا کو ٹریک کرنے کے لیے استعمال کیا جاتا ہے۔
وزن کو متوازن کرنا
لوڈ بیلنسر کی کلوک کا واحد انٹری پوائنٹ ہے اور اسے چپچپا سیشنز کو سپورٹ کرنا چاہیے۔
ایپلیکیشن سرورز
وہ ایک دوسرے کے ساتھ اجزاء کے تعامل کو کنٹرول کرنے کے لیے استعمال کیے جاتے ہیں اور موجودہ آٹومیشن ٹولز اور انفراسٹرکچر آٹومیشن ٹولز کی ڈائنامک اسکیلنگ کا استعمال کرتے ہوئے ورچوئلائز یا کنٹینرائز کیا جا سکتا ہے۔ سب سے عام تعیناتی منظرنامے OpenShift، Kubernates، Rancher میں ہیں۔
یہ پہلا حصہ مکمل کرتا ہے - نظریاتی۔ مضامین کی مندرجہ ذیل سیریز میں، مختلف شناختی فراہم کنندگان کے ساتھ انضمام کی مثالوں اور ترتیبات کی مثالوں پر تبادلہ خیال کیا جائے گا۔
ماخذ: www.habr.com