په هر لوی شرکت کې، او د X5 پرچون ګروپ هیڅ استثنا نه ده، لکه څنګه چې دا وده کوي، د هغو پروژو شمیر چې د کاروونکي واک ته اړتیا لري زیاتیږي. د وخت په تیریدو سره، د یو غوښتنلیک څخه بل ته د کاروونکو بې ساري لیږد ته اړتیا ده، او بیا د یو واحد واحد-سنګ-آن (SSO) سرور کارولو ته اړتیا ده. مګر د څه په اړه کله چې د پیژندنې چمتو کونکي لکه AD یا نور چې اضافي ځانګړتیاوې نلري دمخه په بیلابیلو پروژو کې کارول کیږي. د "پیژندنې بروکرز" په نوم د سیسټمونو یوه ټولګي به ژغورنې ته راشي. تر ټولو فعال د هغې نمایندګۍ دي، لکه کیکلوک، د ګرویټي لاسرسي مدیریت، او داسې نور. ډیری وختونه، د کارولو قضیې توپیر لري: د ماشین تعامل، د کاروونکي ګډون، او داسې نور. حل باید د انعطاف وړ او د توزیع وړ فعالیت ملاتړ وکړي چې کولی شي ټولې اړتیاوې په یوه کې سره یوځای کړي، او دا ډول حلونه زموږ شرکت اوس د اشارې بروکر لري - کیکلوک.
کیکلوک د خلاصې سرچینې پیژندنه او د لاسرسي کنټرول محصول دی چې د RedHat لخوا ساتل کیږي. دا د SSO - RH-SSO په کارولو سره د شرکت محصولاتو اساس دی.
بنسټیز مفهومونه
مخکې له دې چې تاسو د حلونو او طریقو سره معامله پیل کړئ، تاسو باید د پروسو په شرایطو او ترتیب کې پریکړه وکړئ:
پیژندنه د هغه د پیژندونکي لخوا د موضوع پیژندلو لپاره یوه کړنلاره ده (په بل عبارت، دا د نوم، ننوتلو یا شمیرې تعریف دی).
تصدیق کول - دا د تصدیق کولو پروسه ده (کارونکي د پاسورډ سره چک کیږي ، لیک د بریښنایی لاسلیک سره چک کیږي ، او داسې نور)
واکمنۍ - دا سرچینې ته د لاسرسي شرایط دي (د مثال په توګه ، بریښنالیک ته).
د کیکلوک پیژندنې بروکر
کلیکل د خلاصې سرچینې هویت او د لاسرسي مدیریت حل دی چې په IS کې د کارولو لپاره ډیزاین شوی چیرې چې د مایکرو سرویس معمارۍ نمونې کارول کیدی شي.
Keycloak ځانګړتیاوې وړاندې کوي لکه د واحد لاسلیک (SSO)، بروکرډ پیژندنه او ټولنیز ننوتل، د کارونکي فدراسیون، د پیرودونکي اډیپټرونه، اډمین کنسول او د حساب مدیریت کنسول.
د کیکلوک لخوا ملاتړ شوي بنسټیز فعالیت:
- د براوزر غوښتنلیکونو لپاره واحد لاسلیک او واحد لاسلیک کول.
- د OpenID/OAuth 2.0/SAML لپاره ملاتړ.
- د پیژندنې بروکرینګ - د بهرني OpenID Connect یا SAML شناخت چمتو کونکو په کارولو سره تصدیق.
- ټولنیز ننوتل - د کارونکي پیژندنې لپاره د ګوګل، ګیټ هب، فیسبوک، ټویټر لپاره ملاتړ.
- د کارونکي فدراسیون - د LDAP او فعال لارښود سرورونو او نورو پیژندونکو چمتو کونکو څخه د کاروونکو همغږي کول.
- د کربروس پل - د اتوماتیک کارونکي تصدیق لپاره د کربروس سرور کارول.
- اډمین کنسول - د ویب له لارې د تنظیماتو او حل انتخابونو متحد مدیریت لپاره.
- د حساب مدیریت کنسول - د خپلواک کارونکي پروفایل مدیریت لپاره.
- د شرکت د کارپوریټ هویت پراساس د حل تنظیم کول.
- د 2FA تصدیق - د ګوګل تصدیق کونکي یا FreeOTP په کارولو سره د TOTP/HOTP ملاتړ.
- د ننوتلو جریان - د کارونکي ځان ثبت کول، د پټنوم بیرته راګرځول او بیا تنظیم کول، او نور ممکن دي.
- د ناستې مدیریت - مدیران کولی شي د کارونکي ناستې له یوې نقطې څخه اداره کړي.
- د ټوکن نقشه - د کارونکي ځانګړتیاوې، رولونه او نور اړین ځانګړتیاوې په نښه کوي.
- په سیمه، غوښتنلیک او کاروونکو کې د انعطاف وړ پالیسۍ مدیریت.
- د CORS ملاتړ - د پیرودونکي اډاپټرونه د CORS ملاتړ جوړ شوی دی.
- د خدماتو چمتو کونکي انٹرفیس (SPI) - د SPIs لوی شمیر چې تاسو ته اجازه درکوي د سرور مختلف اړخونه تنظیم کړئ: د تصدیق جریان ، د پیژندنې چمتو کونکي ، پروتوکول نقشه کول او نور ډیر څه.
- د جاواسکریپټ غوښتنلیکونو لپاره د پیرودونکي اډاپټرونه، وائلډ فلای، JBoss EAP، فیوز، ټامکاټ، جیټي، پسرلی.
- د مختلف غوښتنلیکونو سره د کار کولو لپاره ملاتړ چې د OpenID Connect انحصار ګوند کتابتون یا SAML 2.0 خدمت چمتو کونکي کتابتون ملاتړ کوي.
- د پلگ انونو په کارولو سره د پراخیدو وړ.
د CI/CD پروسو لپاره، او همدارنګه په کیکلوک کې د مدیریت پروسو اتومات کولو لپاره، REST API/JAVA API کارول کیدی شي. اسناد په بریښنایی بڼه شتون لري:
REST API
جاوا API
د تشبث پیژندنې چمتو کونکي (په اساس)
د کارونکي فدراسیون خدماتو له لارې د کاروونکو تصدیق کولو وړتیا.
د پاس له لارې تصدیق هم کارول کیدی شي - که چیرې کارونکي د کاربروس (LDAP یا AD) سره په ورک سټیشنونو کې تصدیق کړي ، نو بیا دوی د خپل کارن نوم او پټنوم داخلولو پرته په اتوماتيک ډول کیکلوک ته تصدیق کیدی شي.
د تصدیق کولو او د کاروونکو نور واک لپاره، دا ممکنه ده چې یو اړونده DBMS وکاروئ، کوم چې د پراختیایي چاپیریال لپاره خورا پلي کیږي، ځکه چې دا د پروژو په لومړیو مرحلو کې اوږد ترتیبات او ادغام نه لري. په ډیفالټ ډول ، کیکلوک د تنظیماتو او کارونکي ډیټا ذخیره کولو لپاره جوړ شوی DBMS کاروي.
د ملاتړ شوي DBMS لیست پراخه دی او پکې شامل دي: MS SQL، اوریکل، PostgreSQL، MariaDB، اوریکل او نور. تر دې دمه ترټولو ازمول شوي د ماریا ډی بی 12 لپاره اوریکل 1C ریلیز 3.12 RAC او ګیلرا 10.1.19 کلستر دي.
د پیژندنې چمتو کونکي - ټولنیز ننوتل
دا ممکنه ده چې د ټولنیزو شبکو څخه د ننوتلو څخه کار واخلئ. د کاروونکو د تصدیق کولو وړتیا فعالولو لپاره، د کیکلاک اډمین کنسول وکاروئ. د غوښتنلیک کوډ کې هیڅ بدلون ته اړتیا نشته او دا فعالیت د بکس څخه بهر شتون لري او د پروژې په هر مرحله کې فعال کیدی شي.
دا ممکنه ده چې د کارونکي تصدیق لپاره د OpenID/SAML پیژندونکي چمتو کونکي وکاروئ.
په Keycloak کې د OAuth2 په کارولو سره د جواز ورکولو عادي سناریوګانې
د اجازې کوډ جریان - د سرور اړخ غوښتنلیکونو سره کارول کیږي. د اجازې یو له خورا عام ډولونو څخه دی ځکه چې دا د سرور غوښتنلیکونو لپاره ښه مناسب دی چیرې چې د غوښتنلیک سرچینې کوډ او د پیرودونکي ډیټا د بهرنیانو لپاره شتون نلري. په دې حالت کې پروسه د بیا راستنیدو پر بنسټ والړ ده. غوښتنلیک باید د دې وړتیا ولري چې د کارونکي اجنټ (د کارونکي اجنټ) سره اړیکه ونیسي ، لکه ویب براوزر - د کارونکي اجنټ له لارې د لارښود شوي API اختیار کوډونو ترلاسه کولو لپاره.
ضمني جریان - د ګرځنده یا ویب غوښتنلیکونو لخوا کارول کیږي (هغه غوښتنلیکونه چې د کارونکي وسیله پرمخ ځي).
د احتمالي اجازه لیک ډول د ګرځنده او ویب غوښتنلیکونو لخوا کارول کیږي چیرې چې د پیرودونکي محرمیت نشي تضمین کیدی. د ضمني اجازې ډول د کارونکي اجنټ ریډائریکشن هم کاروي ، چیرې چې د لاسرسي نښه په غوښتنلیک کې د نورو کارولو لپاره د کارونکي اجنټ ته لیږدول کیږي. دا د کارونکي په آلې کې کارونکي او نورو غوښتنلیکونو ته نښه چمتو کوي. د دې ډول اجازې اجازه د غوښتنلیک پیژندنه نه تصدیق کوي، او دا پروسه پخپله په ریډیریټ URL باندې تکیه کوي (مخکې له خدمت سره راجستر شوی).
ضمني جریان د لاسرسي ټوکن تازه کولو توکیو ملاتړ نه کوي.
د پیرودونکي اعتبار وړ مرستې جریان - کارول کیږي کله چې غوښتنلیک API ته لاسرسی ومومي. دا ډول اجازه لیک عموما د سرور څخه تر سرور متقابل عمل لپاره کارول کیږي چې باید په شالید کې د فوري کارونکي متقابل عمل پرته ترسره شي. د پیرودونکي د اعتبار ورکولو جریان یو ویب خدمت (محرم پیرودونکي) ته اجازه ورکوي چې د بل ویب خدماتو ته د زنګ وهلو په وخت کې د تصدیق کولو لپاره د کارونکي نقض کولو پرځای خپل سندونه وکاروي. د لوړې کچې امنیت لپاره، د زنګ وهلو خدمت لپاره دا ممکنه ده چې یو سند (د شریک راز پرځای) د اعتبار په توګه وکاروي.
د OAuth2 مشخصات په کې تشریح شوي
د JWT نښه او ګټې
JWT (JSON ویب ټوکن) یو خلاص معیار دی () چې د JSON اعتراض په توګه د ګوندونو تر مینځ د معلوماتو خوندي لیږد لپاره یو تړون او په ځان کې شامل لاره تعریفوي.
د معیار له مخې، نښه په اساس - 64 بڼه کې درې برخې لري، د نقطو لخوا جلا شوي. لومړۍ برخه د سرلیک په نوم یادیږي، کوم چې د ډیجیټل لاسلیک ترلاسه کولو لپاره د ټوکن ډول او د هش الګوریتم نوم لري. دویمه برخه لومړني معلومات ذخیره کوي (کارونکي، ځانګړتیاوې، او نور). دریمه برخه ډیجیټل لاسلیک دی.
. .
هیڅکله په خپل DB کې نښه مه ساتئ. ځکه چې یو باوري نښه د پاسورډ سره مساوي ده، د نښه ذخیره کول په روښانه متن کې د پټنوم ذخیره کولو په څیر دي.
د لاسرسي نښه یوه نښه ده چې خپل مالک ته د خوندي سرور سرچینو ته لاسرسی ورکوي. دا معمولا لنډ ژوند لري او ممکن اضافي معلومات ولري لکه د ګوند IP پته چې د نښې غوښتنه کوي.
نښه تازه کړئ یوه نښه ده چې پیرودونکو ته اجازه ورکوي چې د دوی د ژوند موده پای ته رسیدو وروسته د نوي لاسرسي ټیکونو غوښتنه وکړي. دا نښې معمولا د اوږدې مودې لپاره صادریږي.
د مایکرو سرویس جوړښت کې د کارولو اصلي ګټې:
- د یو وخت تصدیق کولو له لارې مختلف غوښتنلیکونو او خدماتو ته د لاسرسي وړتیا.
- د کارونکي پروفایل کې د یو شمیر اړینو ځانګړتیاو په نشتوالي کې ، دا ممکنه ده چې د ډیټا بډایه کړئ چې په تادیه کې اضافه کیدی شي ، پشمول د اتومات او الوتنې په شمول.
- د فعال غونډو په اړه د معلوماتو ذخیره کولو ته اړتیا نشته، د سرور غوښتنلیک یوازې د لاسلیک تصدیق کولو ته اړتیا لري.
- په تادیاتو کې د اضافي ځانګړتیاو له لارې ډیر انعطاف وړ لاسرسي کنټرول.
- د سرلیک او تادیاتو لپاره د نښه نښه کارول په بشپړ ډول د حل امنیت زیاتوي.
د JWT نښه - جوړښت
سرونکی - په ډیفالټ کې، سرلیک یوازې د نښه ډول او الګوریتم لري چې د کوډ کولو لپاره کارول کیږي.
د نښې ډول په "ټایپ" کیلي کې زیرمه شوی. د 'ډول' کلیمه په JWT کې له پامه غورځول شوې. که د "ټایپ" کیلي شتون ولري، د هغې ارزښت باید JWT وي ترڅو وښيي چې دا اعتراض د JSON ویب ټوکن دی.
دوهم کلیدي "alg" هغه الګوریتم تعریفوي چې د ټوکن کوډ کولو لپاره کارول کیږي. دا باید په ډیفالټ HS256 ته تنظیم شي. سرلیک په بیس 64 کې کوډ شوی دی.
{ "alg": "HS256", "ډول": "JWT"}
پېلوډ (منځپانګه) - تادیه هر هغه معلومات ذخیره کوي چې معاینه کولو ته اړتیا لري. په تادیاتو کې هر کلی د "دعوې" په نوم پیژندل کیږي. د مثال په توګه، تاسو کولی شئ غوښتنلیک یوازې د بلنې (تړل شوي پرومو) له لارې داخل کړئ. کله چې موږ غواړو یو څوک د ګډون لپاره بلنه ورکړو، موږ دوی ته د بلنې لیک لیږو. دا مهمه ده چې وګورئ چې د بریښنالیک پته د هغه چا سره تړاو لري چې بلنه مني، نو موږ به دا پته په تادیه کې شامل کړو، د دې لپاره موږ دا د "بریښنالیک" کیلي کې ذخیره کوو
{ "email": "[ایمیل خوندي شوی]"}
په تادیاتو کې کیلي په خپل سر وي. په هرصورت، دلته یو څو خوندي دي:
- iss (جاری کونکی) - هغه غوښتنلیک پیژني چې له هغې څخه نښه لیږل کیږي.
- فرعي (موضوع) - د نښه موضوع تعریفوي.
- aud (اوریدونکي) د قضیې حساس تارونو یا URIs لړۍ ده چې د دې نښه ترلاسه کونکو لیست دی. کله چې ترلاسه کونکي اړخ د ورکړل شوي کیلي سره JWT ترلاسه کوي ، نو دا باید په ترلاسه کونکو کې د ځان شتون وګوري - که نه نو نښه له پامه غورځوي.
- exp (د ختمیدو وخت) - په ګوته کوي کله چې نښه پای ته ورسیږي. د JWT معیار د دې ټولو پلي کولو ته اړتیا لري ترڅو پای ته رسیدلي ټیکونه رد کړي. د اکسپ کیلي باید د یونیکس په شکل کې د مهال ویش وي.
- nbf (مخکې نه) د یونیکس په شکل کې یو وخت دی چې هغه شیبه ټاکي کله چې نښه د اعتبار وړ شي.
- iat (جاری شوی) - دا کیلي د هغه وخت استازیتوب کوي چې نښه صادره شوې وه او د JWT عمر ټاکلو لپاره کارول کیدی شي. د iat کیلي باید د یونیکس په بڼه کې د مهال ویش وي.
- Jti (JWT ID) - یو تار چې د دې نښه ځانګړی پیژندونکی تعریفوي، د قضیې حساس.
دا مهمه ده چې پوه شئ چې تادیه په کوډ شوي شکل کې نه لیږدول کیږي (که څه هم ټوکنونه ځړول کیدی شي او بیا د کوډ شوي ډیټا لیږدول ممکن وي). نو ځکه، دا نشي کولی کوم پټ معلومات ذخیره کړي. د سرلیک په څیر، د تادیې بار بیس 64 کوډ شوی دی.
لاسلیک - کله چې موږ سرلیک او تادیه ولرو، موږ کولی شو لاسلیک محاسبه کړو.
بیس 64-کوډ شوی: سرلیک او پایلوډ اخیستل کیږي، دوی د نقطې له لارې په تار کې یوځای شوي. بیا دا تار او پټ کیلي د کوډ کولو الګوریتم ته داخلیږي چې په سرلیک کې مشخص شوي ("alg" کیلي). کیلي کیدای شي هر تار وي. اوږد تارونه به خورا غوره وي ځکه چې دا به ډیر وخت ونیسي.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
د کیکلوک ناکامي کلستر آرکیټیکچر جوړول
کله چې د ټولو پروژو لپاره یو واحد کلستر وکاروئ، د SSO حل لپاره زیاتې اړتیاوې شتون لري. کله چې د پروژو شمیر لږ وي، دا اړتیاوې د ټولو پروژو لپاره دومره د پام وړ ندي، په هرصورت، د کاروونکو شمیر او ادغام سره، د شتون او فعالیت اړتیاوې زیاتیږي.
د واحد SSO ناکامۍ خطر زیاتول د حل جوړښت او د بې ځایه اجزاو لپاره کارول شوي میتودونو اړتیاوې ډیروي او د خورا سخت SLA لامل کیږي. په دې برخه کې، ډیری وختونه د پراختیا یا د حلونو د پلي کولو په لومړیو مرحلو کې، پروژې خپل غیر خطا نه زغمونکي زیربنا لري. لکه څنګه چې پرمختګ پرمختګ کوي، دا اړینه ده چې د پراختیا او پیمانه کولو فرصتونه برابر کړي. دا خورا انعطاف وړ دی چې د کانټینر مجازی کولو یا هایبرډ طریقې په کارولو سره د ناکامۍ کلستر رامینځته کړئ.
د فعال/فعال او فعال/غیر فعال کلستر حالتونو کې د کار کولو لپاره، دا اړینه ده چې په اړونده ډیټابیس کې د ډیټا ثبات یقیني کړي - دواړه ډیټابیس نوډونه باید د مختلف جیو ویشل شوي ډیټا مرکزونو ترمنځ په همغږي توګه تکرار شي.
د غلطۍ زغملو نصب کولو ترټولو ساده مثال.
د یو واحد کلستر کارولو ګټې څه دي:
- لوړ شتون او فعالیت.
- د عملیاتي حالتونو لپاره ملاتړ: فعال / فعال، فعال / غیر فعال.
- په متحرک ډول اندازه کولو وړتیا - کله چې د کانټینر مجازی کولو کارول.
- د مرکزي مدیریت او نظارت امکان.
- په پروژو کې د کاروونکو د پیژندلو / تصدیق کولو / مجاز کولو لپاره یو متحد چلند.
- د کارونکي د ښکیلتیا پرته د بیلابیلو پروژو تر مینځ ډیر شفاف تعامل.
- په مختلفو پروژو کې د JWT نښه بیا کارولو وړتیا.
- د باور واحد ټکی.
- د مایکرو خدماتو / کانټینر مجازی کولو په کارولو سره د پروژو ګړندی پیل کول (د اضافي برخو پورته کولو او تنظیم کولو ته اړتیا نشته).
- دا ممکنه ده چې د پلورونکي څخه سوداګریز مالتړ واخلئ.
د کلستر پلان کولو په وخت کې څه باید په پام کې ونیول شي
DBMS
Keycloak د ذخیره کولو لپاره د ډیټابیس مدیریت سیسټم کاروي: حقیقي، پیرودونکي، کاروونکي، او نور.
د DBMS پراخه لړۍ ملاتړ کیږي: MS SQL، اوریکل، MySQL، PostgreSQL. کیکلوک د خپل جوړ شوي اړونده ډیټابیس سره راځي. دا سپارښتنه کیږي چې د غیر بار شوي چاپیریال لپاره وکاروئ - لکه د پراختیا چاپیریال.
د فعال/فعال او فعال/غیر فعال کلستر حالتونو کې کار کولو لپاره، په اړونده ډیټابیس کې د ډیټا تسلسل ته اړتیا ده، او دواړه ډیټابیس کلستر نوډونه په همغږي توګه د ډیټا مرکزونو ترمنځ نقل شوي.
توزیع شوی زیرمه (Infinspan)
د دې لپاره چې کلستر په سمه توګه کار وکړي، د JBoss ډیټا ګریډ په کارولو سره د لاندې کیچ ډولونو اضافي ترکیب ته اړتیا ده:
د تصدیق ناستې - د ځانګړي کارونکي تصدیق کولو پرمهال د معلوماتو خوندي کولو لپاره کارول کیږي. د دې زیرمې څخه غوښتنې معمولا یوازې براوزر او کیکلوک سرور شاملوي، نه غوښتنلیک.
د عمل ټوکن د سناریوګانو لپاره کارول کیږي چیرې چې کارونکي اړتیا لري په غیر همغږي ډول (د بریښنالیک له لارې) یو عمل تایید کړي. د مثال په توګه، د هیر شوي پاسورډ جریان په جریان کې، د ایکشن ټوکنز انفینیسپان کیچ د اړونده عمل ټوکنونو په اړه د میټاډاټا تعقیب ساتلو لپاره کارول کیږي چې دمخه کارول شوي دي، نو دا نشي کارول کیدی.
د دوامداره معلوماتو زیرمه کول او باطلول - ډیټابیس ته د غیر ضروري پوښتنو څخه مخنیوي لپاره د دوامداره ډیټا ذخیره کولو لپاره کارول کیږي. کله چې کوم کیکلوک سرور ډیټا تازه کوي ، په ټولو ډیټا مرکزونو کې نور ټول کیکلوک سرورونه باید پدې اړه پوه شي.
کار - یوازې د کلستر نوډونو او ډیټا مرکزونو ترمینځ د غلط پیغامونو لیږلو لپاره کارول کیږي.
د کارونکي ناستې - د کارونکي غونډو په اړه د معلوماتو ذخیره کولو لپاره کارول کیږي چې د کارونکي براوزر ناستې دورې لپاره اعتبار لري. کیچ باید د پای کارونکي او غوښتنلیک څخه HTTP غوښتنې پروسس کړي.
د وحشي ځواک محافظت - د ناکام شوي ننوتلو په اړه د معلوماتو تعقیب لپاره کارول کیږي.
د بار توازن
د بار بیلانسر کیکلوک ته د ننوتلو واحد نقطه ده او باید د چپچینې غونډو ملاتړ وکړي.
د غوښتنلیک سرورونه
دوی د یو بل سره د اجزاو متقابل عمل کنټرول لپاره کارول کیږي او د موجوده اتومات وسیلو او د زیربنا اتومات وسیلو متحرک پیمانه کولو په کارولو سره مجازی یا کانټینر کیدی شي. په OpenShift، Kubernates، Rancher کې د ګمارنې خورا عام سناریوګانې.
دا لومړۍ برخه پای ته رسوي - نظري. د مقالو په راتلونکې لړۍ کې، د مختلفو پیژندونکو چمتو کونکو سره د ادغام مثالونه او د ترتیباتو مثالونه به تحلیل شي.
سرچینه: www.habr.com