څو میاشتې وړاندې، ما د OpenID Connect سرور پلي کړی و چې زموږ د سلګونو داخلي غوښتنلیکونو لپاره د لاسرسي اداره کول. زموږ د خپلو پرمختګونو څخه، په کوچنۍ پیمانه مناسب، موږ په عمومي توګه منل شوي معیار ته تللي یو. د مرکزي خدماتو له لارې لاسرسی خورا یوازینۍ عملیات ساده کوي، د واکونو پلي کولو لګښت کموي، تاسو ته اجازه درکوي چې ډیری چمتو شوي حلونه ومومئ او د نوي رامینځته کولو په وخت کې خپل مغزونه راټیټ نه کړئ. پدې مقاله کې ، زه به د دې لیږد او هغه خنډونو په اړه وغږیږم چې موږ یې ډکولو اداره کړې.
ډیر وخت دمخه ... دا هرڅه څنګه پیل شول
څو کاله دمخه، کله چې د لاسي کنټرول لپاره ډیری داخلي غوښتنلیکونه شتون درلود، موږ په شرکت کې د لاسرسي کنټرول لپاره یو غوښتنلیک ولیکه. دا یو ساده ریل غوښتنلیک و چې د کارمندانو په اړه معلوماتو سره ډیټابیس سره وصل و ، چیرې چې مختلف فعالیت ته لاسرسی تنظیم شوی و. په ورته وخت کې، موږ لومړی SSO پورته کړ، کوم چې د پیرودونکي او د واک ورکولو سرور څخه د ټوکنونو تصدیق کولو پراساس و، ټوکن په کوډ شوي بڼه کې د څو پیرامیټونو سره لیږدول شوی او د واک ورکولو سرور کې تایید شوی. دا خورا اسانه اختیار نه و ، ځکه چې هر داخلي غوښتنلیک باید د پام وړ منطق بیان کړي ، او د کارمندانو ډیټابیسونه په بشپړ ډول د واک ورکولو سرور سره همغږي شوي.
د یو څه وخت وروسته، موږ پریکړه وکړه چې د مرکزي واک ورکولو دنده ساده کړو. SSO توازن ته لیږدول شوی. د OpenResty په مرسته، یو ټیمپلیټ لوا ته اضافه شوی چې ټوکنونه چک کوي، پوهیدل چې کوم غوښتنلیک ته غوښتنه کیږي، او کولی شي وګوري چې آیا هلته لاسرسی شتون لري. دې کړنالرې د داخلي غوښتنلیکونو ته د لاسرسي کنټرول دنده خورا ساده کړې - د هر غوښتنلیک په کوډ کې ، نور د اضافي منطق تشریح کولو ته اړتیا نه وه. د پایلې په توګه، موږ په بهر کې ټرافيک بند کړ، او غوښتنلیک پخپله د واک په اړه هیڅ نه پوهیږي.
په هرصورت، یوه ستونزه حل شوې پاتې شوه. د هغو غوښتنلیکونو په اړه څه چې د کارمندانو په اړه معلوماتو ته اړتیا لري؟ دا ممکنه وه چې د اختیار ورکولو خدمت لپاره API ولیکئ، مګر بیا تاسو باید د هر داسې غوښتنلیک لپاره اضافي منطق اضافه کړئ. برسېره پردې، موږ غوښتل چې زموږ د خپل ځان لیکل شوي غوښتنلیکونو څخه یو له انحصار څخه ځان خلاص کړو، کوم چې وروسته به په OpenSource کې زموږ د داخلي واک سرور سرور کې ژباړل شي. په دې اړه به بل وخت خبرې وکړو. د دواړو ستونزو د حل لاره OAuth وه.
عام معیارونو ته
OAuth یو د پوهیدو وړ دی، په عمومي توګه د منلو وړ تصویب معیار دی، مګر ځکه چې یوازې د دې فعالیت کافي نه دی، دوی سمدلاسه د OpenID Connect (OIDC) په اړه غور کول پیل کړل. OIDC پخپله د خلاص تصدیق معیار دریم پلي کول دي، کوم چې د OAuth 2.0 پروتوکول (د پرانیستې اجازه ورکولو پروتوکول) کې اضافه شوي. دا حل د پای کارونکي په اړه د معلوماتو نشتوالي ستونزه وتړي، او دا هم امکان لري چې د جواز چمتو کونکي بدل کړي.
په هرصورت، موږ یو ځانګړی چمتو کونکی غوره نه کړ او پریکړه یې وکړه چې زموږ د موجوده واک سرور لپاره د OIDC سره ادغام اضافه کړو. د دې پریکړې په حق کې دا حقیقت و چې OIDC د پای کارونکي واک په شرایطو کې خورا انعطاف منونکی دی. په دې توګه، دا ممکنه وه چې ستاسو په اوسني واک سرور کې د OIDC مالتړ پلي کړئ.
زموږ د خپل OIDC سرور پلي کولو لاره
1) مطلوبه بڼه ته معلومات راوړل
د OIDC مدغم کولو لپاره ، دا اړینه ده چې د اوسني کارونکي ډیټا په داسې شکل کې راوړو چې د معیار لخوا د پوهیدو وړ وي. په OIDC کې دې ته ادعاګانې ویل کیږي. ادعاګانې د کارونکي ډیټابیس (نوم، بریښنالیک، تلیفون، او نور) کې حتمي ساحې دي. شتون لري ، او هر هغه څه چې پدې لیست کې شامل ندي دودیز ګڼل کیږي. له همدې امله ، لومړی ټکی چې تاسو ورته اړتیا لرئ پاملرنه وکړئ که تاسو غواړئ د اوسني OIDC چمتو کونکي غوره کړئ د نوي برانډونو مناسب تنظیم کولو امکان دی.
د هالمارک ګروپ په لاندې فرعي سیټ کې یوځای شوی - ساحه. د واک ورکولو په جریان کې ، د لاسرسي غوښتنه کیږي نه ځانګړي برانڈونو ته ، مګر سکوپونو ته ، حتی که د ساحې څخه ځینې برانډونه اړتیا نلري.
2) د اړتیا وړ مرستې پلي کول
د OIDC ادغام بله برخه د واک ډولونو انتخاب او پلي کول دي، چې تش په نامه مرستې دي. د ټاکل شوي غوښتنلیک او واک ورکولو سرور تر مینځ د متقابل عمل نور سناریو به په ټاکل شوي مرستې پورې اړه ولري. د سمې مرستې غوره کولو لپاره یو مثالی سکیم په لاندې شکل کې ښودل شوی.
زموږ د لومړي غوښتنلیک لپاره، موږ خورا عام بسپنه کارولې، د واک ورکولو کوډ. د نورو څخه یې توپیر دا دی چې دا درې مرحلې دي، د بیلګې په توګه. د اضافي ازموینې لاندې دی. لومړی، کاروونکي د اجازې لپاره غوښتنه کوي، یو نښه ترلاسه کوي - د اجازې کوډ، بیا د دې نښه سره، لکه د سفر لپاره د ټکټ سره، د لاسرسي نښه غوښتنه کوي. د دې اجازې سکریپټ ټول اصلي متقابل عمل د غوښتنلیک او اختیار ورکولو سرور ترمینځ د لارښودونو پراساس دی. تاسو کولی شئ د دې مرستې په اړه نور ولولئ .
OAuth دې مفکورې ته غاړه کیږدي چې د واک ترلاسه کولو وروسته ترلاسه شوي د لاسرسي نښه باید لنډمهاله وي او په اوسط ډول په هرو 10 دقیقو کې بدل شي. د واک ورکولو کوډ مرسته د لارښودونو له لارې درې مرحلې تایید دی ، په هرو 10 دقیقو کې د داسې یو ګام بدلولو لپاره ، په ریښتیا سره ، د سترګو لپاره خورا خوندور کار ندی. د دې ستونزې د حل لپاره، یو بل وړیا مرستې شتون لري - ریفریش ټوکن، کوم چې موږ په خپل هیواد کې هم کارولی. دلته هرڅه اسانه دي. د بلې مرستې څخه د تایید په جریان کې، د اصلي لاسرسي نښه سربیره، یو بل خپور شوی - ریفریش ټوکن، کوم چې یوازې یو ځل کارول کیدی شي او د هغې ژوند معمولا ډیر اوږد وي. د دې ریفریش ټوکن سره، کله چې د اصلي لاسرسي نښه TTL (د ژوند کولو وخت) پای ته ورسیږي، د نوي لاسرسي نښه غوښتنه به د بلې مرستې پای ته ورسیږي. کارول شوی ریفریش ټوکن سمدلاسه صفر ته بیا تنظیم شوی. دا چک دوه مرحلې دی او په شالید کې ترسره کیدی شي، په ناڅاپي توګه کارونکي ته.
3) د دودیز ډیټا محصول فارمیټونه تنظیم کړئ
وروسته له دې چې غوره شوي مرستې پلي کیږي، د واک ورکولو کار کوي، دا د پای کارونکي په اړه د معلوماتو ترلاسه کولو ارزښت لري. OIDC د دې لپاره جلا پای ټکی لري، چیرې چې تاسو کولی شئ د خپل اوسني لاسرسي نښه سره د کاروونکي ډیټا غوښتنه وکړئ او که دا تازه وي. او که چیرې د کارونکي ډیټا ډیری وختونه بدلون ونلري، او تاسو اړتیا لرئ چې اوسني ډیری وختونه تعقیب کړئ، تاسو کولی شئ د JWT ټوکن په څیر داسې حل ته ورسیږئ. دا نښې هم د معیار لخوا ملاتړ کیږي. د JWT نښه پخپله درې برخې لري: سرلیک (د ټوکن په اړه معلومات)، تادیه (هر اړین معلومات) او لاسلیک (لاسلیک، نښه د سرور لخوا لاسلیک شوی او تاسو کولی شئ وروسته د دې لاسلیک سرچینه وګورئ).
د OIDC په تطبیق کې، د JWT نښه د id_token په نوم یادیږي. دا د عادي لاسرسي نښه سره غوښتنه کیدی شي او ټول هغه څه پاتې دي چې د لاسلیک تصدیق کول دي. د واک ورکولو سرور د دې لپاره جلا پای ټکی لري چې په بڼه کې د عامه کلیدونو سره . او د دې خبرې کول، دا د یادونې وړ ده چې یو بل پای ټکی دی، کوم چې د معیار پر بنسټ د OIDC سرور اوسنی ترتیب منعکس کوي. دا د پای ټکي ټول پتې لري (د عامه کلیدي حلقې پته په شمول چې د لاسلیک کولو لپاره کارول کیږي)، ملاتړ شوي برانډونه او سکوپونه، د کوډ کولو الګوریتم کارول شوي، ملاتړ شوي مرستې، او داسې نور.
د مثال په توګه په ګوګل کې:
{
"issuer": "https://accounts.google.com",
"authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
"device_authorization_endpoint": "https://oauth2.googleapis.com/device/code",
"token_endpoint": "https://oauth2.googleapis.com/token",
"userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
"revocation_endpoint": "https://oauth2.googleapis.com/revoke",
"jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
"response_types_supported": [
"code",
"token",
"id_token",
"code token",
"code id_token",
"token id_token",
"code token id_token",
"none"
],
"subject_types_supported": [
"public"
],
"id_token_signing_alg_values_supported": [
"RS256"
],
"scopes_supported": [
"openid",
"email",
"profile"
],
"token_endpoint_auth_methods_supported": [
"client_secret_post",
"client_secret_basic"
],
"claims_supported": [
"aud",
"email",
"email_verified",
"exp",
"family_name",
"given_name",
"iat",
"iss",
"locale",
"name",
"picture",
"sub"
],
"code_challenge_methods_supported": [
"plain",
"S256"
],
"grant_types_supported": [
"authorization_code",
"refresh_token",
"urn:ietf:params:oauth:grant-type:device_code",
"urn:ietf:params:oauth:grant-type:jwt-bearer"
]
}په دې توګه، د id_token په کارولو سره، تاسو کولی شئ ټول اړین نښه نښه د ټوکن تادیه ته انتقال کړئ او هر ځل د کاروونکي ډیټا غوښتنه کولو لپاره د واک ورکولو سرور سره اړیکه ونیسئ. د دې تګلارې نیمګړتیا دا ده چې د سرور څخه د کاروونکي ډیټا کې بدلون سمدستي نه راځي، مګر د نوي لاسرسي نښه سره.
د تطبیق پایلې
نو، زموږ د خپل OIDC سرور پلي کولو وروسته او د غوښتنلیک اړخ کې دې ته د اړیکو تنظیمولو وروسته، موږ د کاروونکو په اړه د معلوماتو لیږدولو ستونزه حل کړه.
څرنګه چې OIDC یو خلاص معیار دی، موږ د موجوده چمتو کونکي یا سرور پلي کولو غوره کولو اختیار لرو. موږ کیکلوک هڅه وکړه ، کوم چې د تنظیم کولو لپاره خورا اسانه وګرځید ، د غوښتنلیک اړخ کې د پیوستون ترتیبات تنظیم او بدلولو وروسته ، دا د تګ لپاره چمتو دی. د غوښتنلیک اړخ کې، ټول هغه څه چې پاتې دي د پیوستون ترتیبات بدلول دي.
د موجوده حلونو په اړه خبرې کول
زموږ په سازمان کې، د لومړي OIDC سرور په توګه، موږ خپل پلي کول راټول کړل، کوم چې د اړتیا سره سم ضمیمه شوي. د نورو چمتو شوي حلونو تفصيلي بیاکتنې وروسته، موږ کولی شو ووایو چې دا یو مهم ټکی دی. د دوی د خپل سرور پلي کولو پریکړې په حق کې ، د اړتیا وړ فعالیت نشتوالي کې د چمتو کونکو لخوا اندیښنې شتون درلود ، په بیله بیا د زاړه سیسټم شتون چې پکې د ځینې خدماتو لپاره مختلف دودیز واکونه شتون درلود او خورا ډیر. د کارمندانو په اړه معلومات لا دمخه زیرمه شوي. په هرصورت، په چمتو شوي پلي کولو کې، د ادغام لپاره اسانتیاوې شتون لري. د مثال په توګه، Keycloak خپل د کاروونکي مدیریت سیسټم لري او ډاټا په مستقیم ډول په دې کې زیرمه شوي، او دا به ستونزمن نه وي چې ستاسو کاروونکي هلته تیر شي. د دې کولو لپاره ، کیکلوک یو API لري چې تاسو ته به اجازه درکړي په بشپړ ډول د لیږد ټول اړین عملونه ترسره کړئ.
د تصدیق شوي، زړه پورې، زما په نظر، د تطبیق بله بیلګه اوری هایډرا ده. دا په زړه پورې ده ځکه چې دا د مختلفو برخو څخه جوړه ده. د ادغام لپاره، تاسو اړتیا لرئ چې د خپل کاروونکي مدیریت خدمت د دوی د واک ورکولو خدمت سره وصل کړئ او د اړتیا سره سم پراخ کړئ.
کیکلوک او اوری هایډرا یوازې د شیلف څخه بهر حلونه ندي. دا غوره ده چې د OpenID بنسټ لخوا تصدیق شوي تطبیق غوره کړئ. دا حلونه معمولا د OpenID تصدیق بیج لري.
همدارنګه د موجوده تادیه کونکو په اړه مه هېروئ که تاسو نه غواړئ خپل OIDC سرور وساتئ. نن ورځ ډیری ښه اختیارونه شتون لري.
نور څه شی دی
په نږدې راتلونکي کې، موږ به په بل ډول داخلي خدماتو ته ترافیک وتړو. موږ پلان لرو چې خپل اوسنی SSO د OAuth پراساس پراکسي ته د OpenResty په کارولو سره په توازن کې انتقال کړو. دلته لا دمخه ډیری چمتو شوي حلونه شتون لري، د بیلګې په توګه:
اضافي توکي
- د JWT ټوکنونو اعتبار لپاره ښه خدمت
- د تصدیق شوي OIDC پلي کولو لیست
سرچینه: www.habr.com