মাইক্রোসার্ভিস আর্কিটেকচারের উপর SSO। আমরা কীক্লোক ব্যবহার করি। অংশ 1

যেকোন বড় কোম্পানিতে এবং X5 রিটেল গ্রুপ এর ব্যতিক্রম নয়, এটি বিকাশের সাথে সাথে ব্যবহারকারীর অনুমোদনের প্রয়োজন এমন প্রকল্পের সংখ্যা বৃদ্ধি পায়। সময়ের সাথে সাথে, এক অ্যাপ্লিকেশন থেকে অন্য অ্যাপ্লিকেশনে ব্যবহারকারীদের বিরামহীন স্থানান্তর প্রয়োজন, এবং তারপরে একটি একক সিঙ্গেল-সিং-অন (এসএসও) সার্ভার ব্যবহার করার প্রয়োজন রয়েছে। কিন্তু কী হবে যখন পরিচয় প্রদানকারী যেমন AD বা অন্যদের যাদের অতিরিক্ত বৈশিষ্ট্য নেই তারা ইতিমধ্যেই বিভিন্ন প্রকল্পে ব্যবহার করা হয়। "শনাক্তকরণ দালাল" নামে এক শ্রেণীর সিস্টেম উদ্ধারে আসবে। সবচেয়ে কার্যকরী হল এর প্রতিনিধি, যেমন কীক্লোক, গ্র্যাভিটি অ্যাক্সেস ম্যানেজমেন্ট, ইত্যাদি। বেশিরভাগ ক্ষেত্রে, ব্যবহারের ক্ষেত্রে ভিন্ন হতে পারে: মেশিনের মিথস্ক্রিয়া, ব্যবহারকারীর অংশগ্রহণ, ইত্যাদি। সমাধানটি অবশ্যই নমনীয় এবং মাপযোগ্য কার্যকারিতা সমর্থন করবে যা একটিতে সমস্ত প্রয়োজনীয়তা একত্রিত করতে পারে, এবং এই জাতীয় সমাধানগুলির জন্য আমাদের কোম্পানির এখন একটি ইঙ্গিত ব্রোকার রয়েছে - কীক্লোক।

কীক্লোক হল একটি ওপেন সোর্স আইডেন্টিটি এবং এক্সেস কন্ট্রোল প্রোডাক্ট যা রেডহ্যাট দ্বারা পরিচালিত হয়। এটি SSO - RH-SSO ব্যবহার করে কোম্পানির পণ্যগুলির জন্য ভিত্তি।

মৌলিক ধারণা

আপনি সমাধান এবং পন্থাগুলি মোকাবেলা শুরু করার আগে, আপনাকে প্রক্রিয়াগুলির শর্তাবলী এবং ক্রম অনুসারে সিদ্ধান্ত নেওয়া উচিত:

সনাক্ত একটি বিষয়কে তার শনাক্তকারী দ্বারা সনাক্ত করার একটি পদ্ধতি (অন্য কথায়, এটি একটি নাম, লগইন বা সংখ্যার সংজ্ঞা)।

প্রমাণীকরণ - এটি একটি প্রমাণীকরণ পদ্ধতি (ব্যবহারকারীকে একটি পাসওয়ার্ড দিয়ে পরীক্ষা করা হয়, চিঠিটি একটি বৈদ্যুতিন স্বাক্ষর দিয়ে পরীক্ষা করা হয়, ইত্যাদি)

অনুমোদন - এটি একটি সংস্থান অ্যাক্সেসের বিধান (উদাহরণস্বরূপ, ই-মেইলে)।

পরিচয় দালাল কীক্লোক

চাবিকাঠি একটি ওপেন সোর্স আইডেন্টিটি এবং অ্যাক্সেস ম্যানেজমেন্ট সলিউশন যা IS-এ ব্যবহারের জন্য ডিজাইন করা হয়েছে যেখানে মাইক্রোসার্ভিস আর্কিটেকচার প্যাটার্ন ব্যবহার করা যেতে পারে।

Keycloak একক সাইন-অন (SSO), ব্রোকার্ড আইডেন্টিটি এবং সোশ্যাল লগইন, ইউজার ফেডারেশন, ক্লায়েন্ট অ্যাডাপ্টার, অ্যাডমিন কনসোল এবং অ্যাকাউন্ট ম্যানেজমেন্ট কনসোলের মতো বৈশিষ্ট্যগুলি অফার করে৷

মূল কার্যকারিতা কীক্লোক দ্বারা সমর্থিত:

• ব্রাউজার অ্যাপ্লিকেশনের জন্য একক-সাইন অন এবং একক-সাইন আউট।
• OpenID/OAuth 2.0/SAML-এর জন্য সমর্থন।
• আইডেন্টিটি ব্রোকারিং - বহিরাগত OpenID কানেক্ট বা SAML পরিচয় প্রদানকারী ব্যবহার করে প্রমাণীকরণ।
• সামাজিক লগইন - ব্যবহারকারী সনাক্তকরণের জন্য গুগল, গিটহাব, ফেসবুক, টুইটার সমর্থন।
• ব্যবহারকারী ফেডারেশন - LDAP এবং অ্যাক্টিভ ডিরেক্টরি সার্ভার এবং অন্যান্য পরিচয় প্রদানকারী থেকে ব্যবহারকারীদের সিঙ্ক্রোনাইজেশন।
• Kerberos সেতু - স্বয়ংক্রিয় ব্যবহারকারী প্রমাণীকরণের জন্য একটি Kerberos সার্ভার ব্যবহার করে।
• অ্যাডমিন কনসোল - ওয়েবের মাধ্যমে সেটিংস এবং সমাধান বিকল্পগুলির একীভূত পরিচালনার জন্য।
• অ্যাকাউন্ট ম্যানেজমেন্ট কনসোল - ব্যবহারকারীর প্রোফাইলের স্ব-ব্যবস্থাপনার জন্য।
• কোম্পানির কর্পোরেট পরিচয়ের উপর ভিত্তি করে সমাধানের কাস্টমাইজেশন।
• 2FA প্রমাণীকরণ - TOTP/HOTP সমর্থন Google প্রমাণীকরণকারী বা FreeOTP ব্যবহার করে।
• লগইন প্রবাহ - ব্যবহারকারীর স্ব-নিবন্ধন, পাসওয়ার্ড পুনরুদ্ধার এবং পুনরায় সেট করা এবং অন্যান্যগুলি সম্ভব।
• সেশন ম্যানেজমেন্ট - অ্যাডমিনিস্ট্রেটররা একক পয়েন্ট থেকে ব্যবহারকারীর সেশন পরিচালনা করতে পারে।
• টোকেন ম্যাপার - টোকেনগুলিতে ব্যবহারকারীর বৈশিষ্ট্য, ভূমিকা এবং অন্যান্য প্রয়োজনীয় বৈশিষ্ট্যগুলিকে আবদ্ধ করে৷
• ক্ষেত্র, অ্যাপ্লিকেশন এবং ব্যবহারকারীদের মধ্যে নমনীয় নীতি ব্যবস্থাপনা।
• CORS সমর্থন - ক্লায়েন্ট অ্যাডাপ্টারগুলিতে অন্তর্নির্মিত CORS সমর্থন রয়েছে৷
• সার্ভিস প্রোভাইডার ইন্টারফেস (SPI) - প্রচুর সংখ্যক SPI যা আপনাকে সার্ভারের বিভিন্ন দিক কাস্টমাইজ করতে দেয়: প্রমাণীকরণ প্রবাহ, পরিচয় প্রদানকারী, প্রোটোকল ম্যাপিং এবং আরও অনেক কিছু।
• JavaScript অ্যাপ্লিকেশন, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring এর জন্য ক্লায়েন্ট অ্যাডাপ্টার।
• OpenID কানেক্ট রিলাইং পার্টি লাইব্রেরি বা SAML 2.0 পরিষেবা প্রদানকারী লাইব্রেরি সমর্থন করে এমন বিভিন্ন অ্যাপ্লিকেশনের সাথে কাজ করার জন্য সমর্থন।
• প্লাগইন ব্যবহার করে প্রসারণযোগ্য।

CI/CD প্রসেসের জন্য, সেইসাথে Keycloak-এ ব্যবস্থাপনা প্রক্রিয়াগুলির অটোমেশনের জন্য, REST API/JAVA API ব্যবহার করা যেতে পারে। ডকুমেন্টেশন ইলেকট্রনিকভাবে উপলব্ধ:

বিশ্রাম এপিআই https://www.keycloak.org/docs-api/8.0/rest-api/index.html
জাভা API https://www.keycloak.org/docs-api/8.0/javadocs/index.html

এন্টারপ্রাইজ আইডেন্টিটি প্রোভাইডার (অন-প্রিমাইজ)

ব্যবহারকারী ফেডারেশন পরিষেবার মাধ্যমে ব্যবহারকারীদের প্রমাণীকরণ করার ক্ষমতা।

পাস-থ্রু প্রমাণীকরণও ব্যবহার করা যেতে পারে - ব্যবহারকারীরা যদি Kerberos (LDAP বা AD) দিয়ে ওয়ার্কস্টেশনের বিরুদ্ধে প্রমাণীকরণ করে, তাহলে তাদের ব্যবহারকারীর নাম এবং পাসওয়ার্ড আবার প্রবেশ না করেই স্বয়ংক্রিয়ভাবে কীক্লোকে প্রমাণীকরণ করা যেতে পারে।

ব্যবহারকারীদের প্রমাণীকরণ এবং আরও অনুমোদনের জন্য, একটি রিলেশনাল ডিবিএমএস ব্যবহার করা সম্ভব, যা উন্নয়ন পরিবেশের জন্য সবচেয়ে বেশি প্রযোজ্য, কারণ এটি প্রকল্পের প্রাথমিক পর্যায়ে দীর্ঘ সেটিংস এবং একীকরণ জড়িত নয়। ডিফল্টরূপে, কীক্লোক সেটিংস এবং ব্যবহারকারীর ডেটা সঞ্চয় করতে একটি অন্তর্নির্মিত DBMS ব্যবহার করে।

সমর্থিত DBMS-এর তালিকা বিস্তৃত এবং এতে রয়েছে: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle এবং অন্যান্য। মারিয়াডিবি 12 এর জন্য ওরাকল 1সি রিলিজ3.12 আরএসি এবং গ্যালেরা 10.1.19 ক্লাস্টার এখন পর্যন্ত সবচেয়ে বেশি পরীক্ষা করা হয়েছে।

পরিচয় প্রদানকারী - সামাজিক লগইন

সামাজিক নেটওয়ার্ক থেকে লগইন ব্যবহার করা সম্ভব। ব্যবহারকারীদের প্রমাণীকরণ করার ক্ষমতা সক্রিয় করতে, Keycloack অ্যাডমিন কনসোল ব্যবহার করুন। অ্যাপ্লিকেশন কোড পরিবর্তনের প্রয়োজন নেই এবং এই কার্যকারিতা বাক্সের বাইরে উপলব্ধ এবং প্রকল্পের যেকোনো পর্যায়ে সক্রিয় করা যেতে পারে।

ব্যবহারকারীর প্রমাণীকরণের জন্য OpenID/SAML পরিচয় প্রদানকারী ব্যবহার করা সম্ভব।

কীক্লোকে OAuth2 ব্যবহার করে সাধারণ অনুমোদনের পরিস্থিতি

অনুমোদন কোড প্রবাহ - সার্ভার-সাইড অ্যাপ্লিকেশনের সাথে ব্যবহৃত। অনুমোদনের অনুমতির সবচেয়ে সাধারণ ধরনগুলির মধ্যে একটি কারণ এটি সার্ভার অ্যাপ্লিকেশনগুলির জন্য উপযুক্ত যেখানে অ্যাপ্লিকেশনটির সোর্স কোড এবং ক্লায়েন্ট ডেটা বহিরাগতদের কাছে উপলব্ধ নয়৷ এই ক্ষেত্রে প্রক্রিয়াটি পুনর্নির্দেশের উপর ভিত্তি করে। ব্যবহারকারী এজেন্টের মাধ্যমে পুনঃনির্দেশিত API অনুমোদন কোডগুলি পেতে অ্যাপ্লিকেশনটিকে অবশ্যই একটি ব্যবহারকারী এজেন্ট (ব্যবহারকারী-এজেন্ট), যেমন একটি ওয়েব ব্রাউজারের সাথে যোগাযোগ করতে সক্ষম হতে হবে৷

অন্তর্নিহিত প্রবাহ - মোবাইল বা ওয়েব অ্যাপ্লিকেশন দ্বারা ব্যবহৃত (ব্যবহারকারীর ডিভাইসে চলমান অ্যাপ্লিকেশন)।

অন্তর্নিহিত অনুমোদন অনুমতি প্রকার মোবাইল এবং ওয়েব অ্যাপ্লিকেশন দ্বারা ব্যবহৃত হয় যেখানে ক্লায়েন্ট গোপনীয়তা নিশ্চিত করা যায় না। অন্তর্নিহিত অনুমতির ধরনটি ব্যবহারকারী এজেন্ট পুনঃনির্দেশও ব্যবহার করে, যেখানে অ্যাক্সেস টোকেনটি অ্যাপ্লিকেশনটিতে আরও ব্যবহারের জন্য ব্যবহারকারী এজেন্টকে দেওয়া হয়। এটি ব্যবহারকারীর ডিভাইসে ব্যবহারকারী এবং অন্যান্য অ্যাপ্লিকেশনের জন্য টোকেনটি উপলব্ধ করে। এই ধরনের অনুমোদনের অনুমতি অ্যাপ্লিকেশনটির পরিচয় প্রমাণীকরণ করে না এবং প্রক্রিয়াটি নিজেই একটি পুনঃনির্দেশ URL এর উপর নির্ভর করে (পূর্বে পরিষেবার সাথে নিবন্ধিত)।

অন্তর্নিহিত প্রবাহ অ্যাক্সেস টোকেন রিফ্রেশ টোকেন সমর্থন করে না।

ক্লায়েন্ট শংসাপত্র অনুদান প্রবাহ — যখন অ্যাপ্লিকেশন API অ্যাক্সেস করে তখন ব্যবহার করা হয়। এই ধরনের অনুমোদনের অনুমতি সাধারণত সার্ভার-টু-সার্ভার ইন্টারঅ্যাকশনের জন্য ব্যবহৃত হয় যা অবিলম্বে ব্যবহারকারীর ইন্টারঅ্যাকশন ছাড়াই ব্যাকগ্রাউন্ডে করা উচিত। ক্লায়েন্ট শংসাপত্র মঞ্জুরি প্রবাহ একটি ওয়েব পরিষেবা (গোপনীয় ক্লায়েন্ট) অন্য ওয়েব পরিষেবাতে কল করার সময় প্রমাণীকরণের জন্য ব্যবহারকারীর ছদ্মবেশী করার পরিবর্তে তার নিজস্ব শংসাপত্রগুলি ব্যবহার করার অনুমতি দেয়৷ উচ্চ স্তরের নিরাপত্তার জন্য, কলিং পরিষেবার জন্য শংসাপত্র (একটি ভাগ করা গোপনীয়তার পরিবর্তে) একটি শংসাপত্র হিসাবে ব্যবহার করা সম্ভব৷

OAuth2 স্পেসিফিকেশন বর্ণনা করা হয়েছে
আরএফসি -6749
আরএফসি -8252
আরএফসি -6819

JWT টোকেন এবং এর সুবিধা

JWT (JSON ওয়েব টোকেন) একটি ওপেন স্ট্যান্ডার্ড (https://tools.ietf.org/html/rfc7519) যা একটি JSON অবজেক্ট হিসাবে পক্ষগুলির মধ্যে নিরাপদে তথ্য স্থানান্তর করার একটি কম্প্যাক্ট এবং স্বয়ংসম্পূর্ণ উপায় সংজ্ঞায়িত করে৷

স্ট্যান্ডার্ড অনুসারে, টোকেনটি বেস-64 বিন্যাসে তিনটি অংশ নিয়ে গঠিত, বিন্দু দ্বারা পৃথক করা হয়েছে। প্রথম অংশটিকে শিরোনাম বলা হয়, এতে টোকেনের ধরন এবং ডিজিটাল স্বাক্ষর পাওয়ার জন্য হ্যাশ অ্যালগরিদমের নাম রয়েছে। দ্বিতীয় অংশ মৌলিক তথ্য সংরক্ষণ করে (ব্যবহারকারী, বৈশিষ্ট্য, ইত্যাদি)। তৃতীয় অংশ ডিজিটাল স্বাক্ষর।

. .
আপনার ডিবিতে কখনই একটি টোকেন সংরক্ষণ করবেন না। যেহেতু একটি বৈধ টোকেন একটি পাসওয়ার্ডের সমতুল্য, টোকেন সংরক্ষণ করা পরিষ্কার পাঠ্যে পাসওয়ার্ড সংরক্ষণ করার মতো।
অ্যাক্সেস টোকেন একটি টোকেন যা এর মালিককে সুরক্ষিত সার্ভার সংস্থানগুলিতে অ্যাক্সেস দেয়। এটি সাধারণত একটি সংক্ষিপ্ত জীবনকাল থাকে এবং অতিরিক্ত তথ্য বহন করতে পারে যেমন টোকেন অনুরোধকারী পক্ষের IP ঠিকানা।

টোকেন রিফ্রেশ করুন একটি টোকেন যা ক্লায়েন্টদের তাদের জীবদ্দশায় মেয়াদ শেষ হওয়ার পরে নতুন অ্যাক্সেস টোকেন অনুরোধ করতে দেয়। এই টোকেনগুলি সাধারণত দীর্ঘ সময়ের জন্য জারি করা হয়।

মাইক্রোসার্ভিস আর্কিটেকচারে ব্যবহারের প্রধান সুবিধা:

• এককালীন প্রমাণীকরণের মাধ্যমে বিভিন্ন অ্যাপ্লিকেশন এবং পরিষেবা অ্যাক্সেস করার ক্ষমতা।
• ব্যবহারকারীর প্রোফাইলে প্রয়োজনীয় কিছু বৈশিষ্ট্যের অনুপস্থিতিতে, স্বয়ংক্রিয় এবং অন-দ্য-ফ্লাই সহ পেলোডে যোগ করা যেতে পারে এমন ডেটা দিয়ে সমৃদ্ধ করা সম্ভব।
• সক্রিয় সেশন সম্পর্কে তথ্য সংরক্ষণ করার কোন প্রয়োজন নেই, সার্ভার অ্যাপ্লিকেশন শুধুমাত্র স্বাক্ষর যাচাই করতে হবে।
• পেলোডে অতিরিক্ত বৈশিষ্ট্যের মাধ্যমে আরও নমনীয় অ্যাক্সেস নিয়ন্ত্রণ।
• হেডার এবং পেলোডের জন্য একটি টোকেন স্বাক্ষরের ব্যবহার সামগ্রিকভাবে সমাধানের নিরাপত্তা বাড়ায়।

JWT টোকেন - রচনা

হেডার - ডিফল্টরূপে, হেডারে শুধুমাত্র টোকেনের প্রকার এবং এনক্রিপশনের জন্য ব্যবহৃত অ্যালগরিদম থাকে।

টোকেনের ধরনটি "টাইপ" কীতে সংরক্ষণ করা হয়। JWT-এ 'টাইপ' কী উপেক্ষা করা হয়। "টাইপ" কী উপস্থিত থাকলে, এই বস্তুটি একটি JSON ওয়েব টোকেন তা নির্দেশ করতে এর মান অবশ্যই JWT হতে হবে।

দ্বিতীয় কী "alg" টোকেন এনক্রিপ্ট করতে ব্যবহৃত অ্যালগরিদমকে সংজ্ঞায়িত করে। এটি ডিফল্টরূপে HS256 এ সেট করা উচিত। শিরোনামটি base64 এ এনকোড করা হয়েছে।

{ "alg": "HS256", "type": "JWT"}
পেলোড (সামগ্রী) - পেলোড যেকোন তথ্য সঞ্চয় করে যা চেক করা দরকার। পেলোডের প্রতিটি কী একটি "দাবি" হিসাবে পরিচিত। উদাহরণস্বরূপ, আপনি শুধুমাত্র আমন্ত্রণ (বন্ধ প্রচার) দ্বারা আবেদন লিখতে পারেন। আমরা যখন কাউকে অংশগ্রহণের জন্য আমন্ত্রণ জানাতে চাই, তখন আমরা তাদের একটি আমন্ত্রণপত্র পাঠাই। ইমেল ঠিকানাটি আমন্ত্রণ গ্রহণকারী ব্যক্তির অন্তর্গত কিনা তা পরীক্ষা করা গুরুত্বপূর্ণ, তাই আমরা এই ঠিকানাটিকে পেলোডে অন্তর্ভুক্ত করব, এর জন্য আমরা এটি "ইমেল" কীতে সংরক্ষণ করি

{ "ইমেইল": "[ইমেল সুরক্ষিত]" }

পেলোডের কীগুলি নির্বিচারে হতে পারে। যাইহোক, কিছু সংরক্ষিত আছে:

• iss (ইস্যুকারী) - যে আবেদনটি থেকে টোকেন পাঠানো হচ্ছে তা শনাক্ত করে।
• সাব (বিষয়) - টোকেনের বিষয় নির্ধারণ করে।
• aud (শ্রোতা) হল কেস-সংবেদনশীল স্ট্রিং বা URI-এর একটি অ্যারে যা এই টোকেনের প্রাপকদের একটি তালিকা। যখন গ্রহীতা পক্ষ প্রদত্ত কী সহ একটি JWT গ্রহণ করে, তখন এটি অবশ্যই প্রাপকদের মধ্যে উপস্থিতি পরীক্ষা করতে হবে - অন্যথায় টোকেন উপেক্ষা করুন।
• exp (মেয়াদ শেষ হওয়ার সময়) - টোকেনের মেয়াদ শেষ হওয়ার সময় নির্দেশ করে। মেয়াদোত্তীর্ণ টোকেন প্রত্যাখ্যান করার জন্য JWT মানক এর সমস্ত বাস্তবায়ন প্রয়োজন। এক্সপ্রেস কীটি অবশ্যই ইউনিক্স বিন্যাসে একটি টাইমস্ট্যাম্প হতে হবে।
• nbf (আগে নয়) হল ইউনিক্স ফরম্যাটে একটি সময় যা টোকেনটি বৈধ হওয়ার মুহূর্ত নির্ধারণ করে।
• iat (ইস্যুড এ) - এই কীটি টোকেন ইস্যু করা সময়ের প্রতিনিধিত্ব করে এবং JWT-এর বয়স নির্ধারণ করতে ব্যবহার করা যেতে পারে। iat কী অবশ্যই ইউনিক্স ফরম্যাটে একটি টাইমস্ট্যাম্প হতে হবে।
• Jti (JWT ID) — একটি স্ট্রিং যা এই টোকেনের অনন্য শনাক্তকারীকে সংজ্ঞায়িত করে, কেস-সংবেদনশীল।

এটা বোঝা গুরুত্বপূর্ণ যে পেলোড এনক্রিপ্ট করা আকারে প্রেরণ করা হয় না (যদিও টোকেন নেস্ট করা যেতে পারে এবং তারপরে এনক্রিপ্ট করা ডেটা প্রেরণ করা সম্ভব)। তাই এটি কোনো গোপন তথ্য সংরক্ষণ করতে পারে না। হেডারের মত, পেলোড বেস64 এনকোডেড।
স্বাক্ষর - যখন আমাদের একটি শিরোনাম এবং পেলোড থাকে, আমরা স্বাক্ষর গণনা করতে পারি।

বেস 64-এনকোডেড: হেডার এবং পেলোড নেওয়া হয়, সেগুলি একটি বিন্দুর মাধ্যমে একটি স্ট্রিংয়ে একত্রিত হয়। তারপর এই স্ট্রিং এবং গোপন কীটি হেডারে ("alg" কী) নির্দিষ্ট এনক্রিপশন অ্যালগরিদমে ইনপুট করা হয়। কী যেকোনো স্ট্রিং হতে পারে। লম্বা স্ট্রিংগুলি সবচেয়ে বেশি পছন্দ করা হবে কারণ এটি তুলতে বেশি সময় লাগবে৷

{"alg":"RSA1_5","payload":"A128CBC-HS256"}

একটি কীক্লোক ফেইলওভার ক্লাস্টার আর্কিটেকচার তৈরি করা

সমস্ত প্রকল্পের জন্য একটি একক ক্লাস্টার ব্যবহার করার সময়, একটি SSO সমাধানের জন্য বর্ধিত প্রয়োজনীয়তা রয়েছে৷ যখন প্রকল্পের সংখ্যা কম হয়, তখন সমস্ত প্রকল্পের জন্য এই প্রয়োজনীয়তাগুলি এতটা লক্ষণীয় নয়, তবে, ব্যবহারকারীর সংখ্যা বৃদ্ধি এবং একীকরণের সাথে, প্রাপ্যতা এবং কর্মক্ষমতা বৃদ্ধির জন্য প্রয়োজনীয়তা বৃদ্ধি পায়।

একক SSO ব্যর্থতার ঝুঁকি বাড়ানো সমাধান আর্কিটেকচারের প্রয়োজনীয়তা এবং অপ্রয়োজনীয় উপাদানগুলির জন্য ব্যবহৃত পদ্ধতিগুলিকে বৃদ্ধি করে এবং একটি খুব শক্ত SLA এর দিকে নিয়ে যায়। এই বিষয়ে, প্রায়শই উন্নয়ন বা সমাধান বাস্তবায়নের প্রাথমিক পর্যায়ে, প্রকল্পগুলির নিজস্ব অ-ফল্ট-সহনশীল অবকাঠামো থাকে। উন্নয়নের অগ্রগতির সাথে সাথে উন্নয়ন এবং স্কেলিংয়ের সুযোগগুলি নির্ধারণ করা প্রয়োজন। কন্টেইনার ভার্চুয়ালাইজেশন বা হাইব্রিড পদ্ধতি ব্যবহার করে একটি ফেইলওভার ক্লাস্টার তৈরি করা সবচেয়ে নমনীয়।

সক্রিয়/সক্রিয় এবং সক্রিয়/প্যাসিভ ক্লাস্টার মোডগুলিতে কাজ করার জন্য, একটি রিলেশনাল ডাটাবেসে ডেটা সামঞ্জস্য নিশ্চিত করতে হবে - উভয় ডাটাবেস নোডকে অবশ্যই বিভিন্ন জিও-ডিস্ট্রিবিউটেড ডেটা সেন্টারের মধ্যে সিঙ্ক্রোনাসভাবে প্রতিলিপি করতে হবে।

একটি ত্রুটি-সহনশীল ইনস্টলেশনের সহজ উদাহরণ।

একটি একক ক্লাস্টার ব্যবহার করার সুবিধা কি কি:

• উচ্চ প্রাপ্যতা এবং কর্মক্ষমতা.
• অপারেটিং মোডগুলির জন্য সমর্থন: সক্রিয় / সক্রিয়, সক্রিয় / নিষ্ক্রিয়।
• গতিশীলভাবে স্কেল করার ক্ষমতা - কন্টেইনার ভার্চুয়ালাইজেশন ব্যবহার করার সময়।
• কেন্দ্রীভূত ব্যবস্থাপনা এবং পর্যবেক্ষণের সম্ভাবনা।
• প্রকল্পগুলিতে ব্যবহারকারীদের সনাক্তকরণ/প্রমাণিকরণ/অনুমোদনের জন্য একীভূত পদ্ধতি।
• ব্যবহারকারীর সম্পৃক্ততা ছাড়াই বিভিন্ন প্রকল্পের মধ্যে আরও স্বচ্ছ মিথস্ক্রিয়া।
• বিভিন্ন প্রকল্পে JWT টোকেন পুনরায় ব্যবহার করার ক্ষমতা।
• বিশ্বাসের একক পয়েন্ট।
• মাইক্রোসার্ভিসেস/কন্টেইনার ভার্চুয়ালাইজেশন ব্যবহার করে দ্রুত প্রজেক্ট চালু করা (অতিরিক্ত কম্পোনেন্ট উত্তোলন এবং কনফিগার করার প্রয়োজন নেই)।
• বিক্রেতার কাছ থেকে বাণিজ্যিক সহায়তা ক্রয় করা সম্ভব।

একটি ক্লাস্টার পরিকল্পনা করার সময় কি দেখতে হবে

ডিবিএমএস

কীক্লোক স্টোর করার জন্য একটি ডাটাবেস ম্যানেজমেন্ট সিস্টেম ব্যবহার করে: রিয়েলম, ক্লায়েন্ট, ব্যবহারকারী, ইত্যাদি।
DBMS-এর একটি বিস্তৃত পরিসর সমর্থিত: MS SQL, Oracle, MySQL, PostgreSQL। কীক্লোক তার নিজস্ব অন্তর্নির্মিত রিলেশনাল ডাটাবেসের সাথে আসে। এটি অ-লোড করা পরিবেশের জন্য ব্যবহার করার সুপারিশ করা হয় - যেমন উন্নয়ন পরিবেশ।

সক্রিয়/সক্রিয় এবং সক্রিয়/প্যাসিভ ক্লাস্টার মোডে কাজ করার জন্য, একটি রিলেশনাল ডাটাবেসে ডেটা সামঞ্জস্য প্রয়োজন, এবং উভয় ডাটাবেস ক্লাস্টার নোডগুলি ডেটা সেন্টারের মধ্যে সিঙ্ক্রোনাসভাবে প্রতিলিপি করা হয়।

বিতরণকৃত ক্যাশে (ইনফিনস্প্যান)

ক্লাস্টারটি সঠিকভাবে কাজ করার জন্য, JBoss ডেটা গ্রিড ব্যবহার করে নিম্নলিখিত ধরণের ক্যাশেগুলির অতিরিক্ত সিঙ্ক্রোনাইজেশন প্রয়োজন:

প্রমাণীকরণ সেশন - একটি নির্দিষ্ট ব্যবহারকারীকে প্রমাণীকরণ করার সময় ডেটা সংরক্ষণ করতে ব্যবহৃত হয়। এই ক্যাশে থেকে অনুরোধগুলি সাধারণত শুধুমাত্র ব্রাউজার এবং কীক্লোক সার্ভার অন্তর্ভুক্ত করে, অ্যাপ্লিকেশন নয়।

অ্যাকশন টোকেনগুলি এমন পরিস্থিতিতে ব্যবহার করা হয় যেখানে ব্যবহারকারীকে অ্যাসিঙ্ক্রোনাসভাবে একটি অ্যাকশন নিশ্চিত করতে হবে (ইমেলের মাধ্যমে)। উদাহরণস্বরূপ, পাসওয়ার্ড ভুলে যাওয়ার সময়, অ্যাকশন টোকেনস ইনফিনিস্প্যান ক্যাশে ইতিমধ্যেই ব্যবহৃত অ্যাকশন টোকেন সম্পর্কিত মেটাডেটা ট্র্যাক রাখতে ব্যবহৃত হয়, তাই এটি পুনরায় ব্যবহার করা যাবে না।

ক্রমাগত ডেটার ক্যাশিং এবং অবৈধকরণ - ডেটাবেসে অপ্রয়োজনীয় প্রশ্নগুলি এড়াতে স্থায়ী ডেটা ক্যাশ করতে ব্যবহৃত হয়। যখন কোন কীক্লোক সার্ভার ডেটা আপডেট করে, তখন সমস্ত ডেটা সেন্টারের অন্যান্য কীক্লোক সার্ভারগুলিকে এটি সম্পর্কে জানতে হবে।

কাজ - শুধুমাত্র ক্লাস্টার নোড এবং ডেটা সেন্টারের মধ্যে অবৈধ বার্তা পাঠাতে ব্যবহৃত হয়।

ব্যবহারকারীর সেশন - ব্যবহারকারীর সেশন সম্পর্কে ডেটা সংরক্ষণ করতে ব্যবহৃত হয় যা ব্যবহারকারীর ব্রাউজার সেশনের সময়কালের জন্য বৈধ। ক্যাশে অবশ্যই শেষ ব্যবহারকারী এবং অ্যাপ্লিকেশন থেকে HTTP অনুরোধগুলি প্রক্রিয়া করবে৷

ব্রুট ফোর্স সুরক্ষা - ব্যর্থ লগইন সম্পর্কে ডেটা ট্র্যাক করতে ব্যবহৃত হয়।

লোড ব্যালেন্সিং

লোড ব্যালেন্সার হল কীক্লোকের একক এন্ট্রি পয়েন্ট এবং এটি অবশ্যই স্টিকি সেশন সমর্থন করবে।

অ্যাপ্লিকেশন সার্ভার

এগুলি একে অপরের সাথে উপাদানগুলির মিথস্ক্রিয়া নিয়ন্ত্রণ করতে ব্যবহৃত হয় এবং বিদ্যমান অটোমেশন সরঞ্জাম এবং অবকাঠামো অটোমেশন সরঞ্জামগুলির গতিশীল স্কেলিং ব্যবহার করে ভার্চুয়ালাইজড বা ধারক করা যেতে পারে। OpenShift, Kubernates, Rancher-এ সবচেয়ে সাধারণ স্থাপনার পরিস্থিতি।

এটি প্রথম অংশটি শেষ করে - তাত্ত্বিক এক। নিবন্ধগুলির পরবর্তী সিরিজগুলিতে, বিভিন্ন পরিচয় প্রদানকারীর সাথে একীকরণের উদাহরণ এবং সেটিংসের উদাহরণগুলি বিশ্লেষণ করা হবে৷

উত্স: www.habr.com