1. Kirish fonı
Loyihada sertifikat va ruxsatnoma boshqaruv tizimini loyihalashda eng muhim hisobga olingan omil xavfsizlikning ishonchliligi edi.
Ayniqsa shifoxonalar tizimi odatiy xizmatlarga qaraganda ancha qat'iy xavfsizlik talablari talab qiladi.
Bemorlarning shaxsiy ma'lumotlari va tibbiy ma'lumotlar bilan ishlagani uchun autentikatsiya tizimining ishonchliligi va kengaytirilishi juda muhim edi.
Boshqaruv bosqichida o'z autentifikatsiya tizimini mustaqil ravishda amalga oshirish imkoniyatlari ham ko'rib chiqildi.
Lekin autentifikatsiya tizimi oddiy kirish funktsiyasidan tashqari, sessiya boshqaruvi, token berish, ruxsatlarni boshqarish, xavfsizlik zaifliklariga qarshi kurash kabi juda murakkab sohalarni o'z ichiga oladi.
Xususan, OAuth2, OpenID Connect, SSO kabi zamonaviy autentifikatsiya standartlarini barqaror qo'llab-quvvatlash kerak bo'lganligi sababli, tasdiqlangan autentifikatsiya yechimlaridan foydalanish yo'lini tanlashga qaror qildik.
O'sha jarayonda tanlangan yechim aynan Keycloak bo'ldi.
Keycloak Red Hat asosidagi ochiq manba IAM (Kimlik va Kirishni boshqarish) yechimi bo'lib, OAuth2, OpenID Connect, SAML kabi standartlarni qo'llab-quvvatlaydi.
Eng muhimi, butun dunyo bo'ylab ishonchliligi tasdiqlangan platforma ekanligi juda katta afzallik edi.
Lekin haqiqiy loyiha o'tkazayotganda oddiy asosiy sozlamalar yordamida hal qilinmaydigan muammolar paydo bo'la boshladi.
Xususan, loyihada oddiy foydalanuvchi autentifikatsiyasi kerak bo'lishidan tashqari, quyidagi kabi murakkab talablar mavjud edi.
- Ko'plab ijrochilar asosidagi huquqiy tuzilma
- Kasalxonalarga qarab foydalanuvchilarni ajratish
- Muddalangan RBAC (Rollga asoslangan kirish nazorati)
- Tashqi shifoxona ma'lumotlari asosida foydalanuvchini tasdiqlash
real-time shaxsni tasdiqlash jarayoni
ichki xizmat biznes mantiqini integratsiya qilish
Asosiy Keycloak tuzilishi kuchli funksiyalarni taqdim etsa-da, ichki a'zolarni boshqarish markaziga yaqin edi.
Biroq, loyihada biz faqat Keycloak ichida foydalanuvchilarni saqlash darajasida emas, balki xizmat biznes jarayoni doirasida foydalanuvchi ma'lumotlarini organik ravishda boshqarishimiz kerak edi.
Xususan, shifoxaning loyihasi xususiyatlari tufayli hech kim ro'yxatdan o'ta olmadi.
Chunki faqat ushbu shifixonada bemor yoki xodim sifatida tasdiqlangan foydalanuvchilar kirish huquqiga ega bo'lishi kerak edi.
Ya'ni, a'zolik jarayonida tashqi shifoxona ma'lumotlarini real vaqtda foydalanuvchi ma'lumotlari bilan solishtirish uchun maxsus tasdiqlash mantiqi zarur edi.
Bunday talablarni hal qilish uchun Keycloak ichki autentikatsiya pipeline'ini kengaytirish usulini qo'llash zarur edi va oxir-oqibat SPI (Xizmat Ko'rsatuvchi Interfeysi) orqali maxsuslashtirilgan tuzilma joriy etildi.
2. SPI(Service Provider Interface) nima
SPI(Service Provider Interface) - bu tashqi tomonidan ramka funktsiyalarini kengaytirishga mo'ljallangan interfeys strukturasini anglatadi.
Umuman olganda, biz ko'p ishlatadigan API (Dasturiy ta'minot interfeysi) dasturchilarning tashqi tizimlarning funktsiyalarini chaqirish uchun mo'ljallangan interfeysga yaqin.
Boshqa tomondan, SPI tushunchasi qarama-qarshidir.
Ramkalar oldindan belgilangan qoidalari va interfeyslariga asoslanib, dasturchilar tomonidan to'g'ridan-to'g'ri amalga oshirilgan implementatsiyalarni qilish, dvigatelning ularni avtomatik ravishda topishi va bajarishi tartibidir.
Ya'ni, SPI “plug-in kengaytirilgan tuzilma” ga yaqin deb qaralishi mumkin.
Keycloak ushbu SPI asosidagi arxitektura atrofida loyihalashtirilgan.
Shu sababli, dasturchilar Keycloak asosiy manba kodini to'g'ridan-to'g'ri o'zgartirmasdan, autentifikatsiya oqimini erkin kengaytirishlari mumkin.
Masalan, quyidagi funksiyalarni SPI shaklida kengaytirish mumkin.
- Foydalanuvchi saqlash (User Storage)
- autentifikatsiya (Authentication)
- voqea (Event Listener)
- Protokol xaritasi (Protocol Mapper)
- Parol siyosati (Password Policy)
- Foydalanuvchi ro'yxatdan o'tish jarayoni
Loyihada ayniqsa Authentication SPI'dan foydalanildi. Amaliyot usuli nisbatan aniq.
Keycloak tomonidan taqdim etilgan interfeys standartiga muvofiq ravishda maxsus klasslarni amalga oshirib, uni JAR fayl shaklida qurib, Keycloak serveriga tarqatamiz.
Keycloak serveri ishga tushgandan so'ng, ichki ravishda SPI amalga oshiruvchilarini avtomatik ravishda skanerlab, yangi tasdiqlash modulini tanib oladi.
Ya'ni, ishlab chiquvchi tomonidan yaratilgan mantiq Keycloak asosiy funksiyalari kabi harakatlanuvchi bo'ladi.
Bu tuzilmaning eng katta afzalligi, dvijarning ichki qismlarini o'zgartirmaslikdir.
Ya'ni, Keycloak versiyasini yangilaganda ham moslashtirilgan kod va dvigatel kodini ajratib saqlab turish mumkin.
Loyihada ushbu tuzilma tufayli shifoxona tizimining o'ziga xos autentifikatsiya talablarini standart autentifikatsiya platformasiga tabiiy ravishda integratsiya qilish mumkin bo'ldi.
3. Authentication Flow mexanizmi
Keycloakning autentifikatsiya tizimi Authentication Flow deb nomlangan quvur tuzilishi ustida ishlaydi.
Foydalanuvchi tizimga kirish yoki ro'yxatdan o'tish jarayonini o'tkazganda, Keycloak belgilangan autentifikatsiya bosqichlarini ketma-ket amalga oshiradi.
Masalan, oddiy kirish jarayoni quyidagi bosqichlardan iborat bo'lishi mumkin.
- Foydalanuvchi ma'lumotlarini kiritish
- Parolni tasdiqlash
- OTP tasdiqlash
- Qo'shimcha tasdiqlash jarayoni
- Tokin berish
Har bir bosqich Execution deb nomlanadigan birlik bilan boshqariladi.
Loyihada ushbu Authentication Flow orasida maxsus tasdiqlash bosqichini kiritish orqali amalga oshirildi.
Avval SPI asosida autentifikatsiya klassini ishlab chiqdik va JAR shaklida qurib, Keycloak serveriga tarqatdik.
Taqsim qilinganidan keyin boshqaruv konsolida ushbu maxsus mantiq yangi autentifikatsiya bajargichi sifatida tan olindi.
Keyin boshqaruvchi ekranida mavjud autentifikatsiya oqimiga bevosita joylashtirilishi mumkin edi.
Ya'ni, standart kirish jarayonining o'rtasida shifoxona tasdiqlash mantiqini tabiiy ravishda bog'lash imkonini berdi.
Amalga oshiruvchi foydalanuvchi kirish yoki ro'yxatdan o'tish harakatini boshlaganda, Keycloak belgilangan tartibga muvofiq har bir autentifikatsiya bosqichini bajaradi. Va maxsus bosqich chaqirilganda, AuthenticationFlowContext ob'ekti uzatiladi. Bu ob'ekt autentifikatsiya oqimining to'liq holatini nazorat qilish uchun juda muhim vosita bo'ldi.
Loyihada AuthenticationFlowContext'dan foydalanib quyidagi ishlar bajarildi.
- Foydalanuvchi kiritgan ma'lumotlarni ko'rish
- Kasal DB ulanishi
- Bemor ma'lumotlarini tasdiqlash
- Xodim ma'lumotlarini tasdiqlash
- Tenant huquqlarini tasdiqlash
- Tasdiqlash muvaffaqiyatli / muvaffaqiyatsiz qayta ishlash
Masalan, foydalanuvchi kiritgan shifoxona identifikatsiya raqami va shaxsiy ma'lumotlarni tashqi shifoxona tizimi bilan real vaqtda taqqoslab, haqiqiy bemor yoki xodim ekanligini aniqladik.
Tasdiqlash muvaffaqiyatli amalga oshganda context.success() chaqirilib, keyingi autentifikatsiya bosqichiga o'tishga ruxsat berildi, muvaffaqiyatsiz bo'lganda esa xato xabari qaytarilib, autentifikatsiyani to'xtatdi.
Bu tuzilma orqali Keycloak asosiy autentifikatsiya oqimini saqlab qolish bilan birga, loyihaga xos biznes mantiqini moslashuvchan ravishda qo'shish imkonini berdi.
4. Texnik muammo: tarqatilgan muhitda ma'lumotlarning birlashuvi muammosi
Amaliyot jarayonida eng qiyin muammolardan biri tarqatilgan muhitda ma'lumotlarning birlashuvi edi.
Xususan, kasalxona foydalanuvchilarini aniqlash jarayonida foydalaniladigan DI (Duplicatsiya ma'lumotlari) qiymatini bir necha autentifikatsiya bosqichlari o'rtasida xavfsiz saqlash kerak edi.
Dastlab, Keycloak ichida taqdim etiladigan AuthNote funksiyasidan foydalanishga harakat qildik.
AuthNote authentikatsiya sessiyasi ichida bosqichlar orasida ma'lumotlarni ulashish uchun vaqtincha saqlash maydoni hisoblanadi.
Yagona server muhiti nisbatan barqaror ishladi. Ammo haqiqiy ishlash muhiti ko'p serverli klaster tuzilishi edi.
Muammo tashqi xavfsizlik modulining autentifikatsiya jarayonida paydo bo'ldi.
Foydalanuvchi autentifikatsiya jarayonida tashqi autentifikatsiya serveriga yo'naltirilib, Keycloakga qaytishi, shu jarayonda sessiya boshqa tuguniga o'tishi holatlariga olib keldi.
Natijada quyidagi muammolar takroran yuzaga keldi.
- AuthNote ma'lumotlari yo'qoladi
- Sessiya mos kelmaydi
- Tasdiqlash holatini qayta tiklash
DI qiymati olish muvaffaqiyatsiz
Foydalanuvchi autentifikatsiyasi to'xtatildi
Dastlab brauzer cookie asosidagi saqlash usulini ko'rib chiqdik.
Shuningdek, Keycloak sessiya sozlamalarini o'zgartirish yoki Sticky Session strukturasi ham sinovdan o'tkazildi.
Lekin bunday usullar tuzilma jihatidan to'liq yechim bo'lishi qiyin edi.
Albatta, kasalxona sertifikatlash tizimi barqarorlik va ishonchlilik jihatidan juda muhim bo'lgani uchun ba'zi vaziyatlarda sertifikatlash muvaffaqiyatsizligi ehtimoli bo'lmasligi kerak edi.
Oxir-oqibat, masalaning asosiysi "tarqatilgan server muhitida barqaror ravishda holat ma'lumotlarini baham ko'rish imkonini beruvchi tuzilmani" yaratish edi.
Bu muammoni hal qilish uchun Keycloak ichki kesh tuzilmasidan to'g'ridan-to'g'ri foydalanish yo'lini tanladik.
5. Muammoni hal qilish: Infinispan asosidagi tarqatilgan kesh dizayni
Tarqatilgan muhitda yuzaga keladigan sertifikat sessiyasi yo'qolish muammosini hal qilish uchun tanlangan texnologiya Infinispan edi.
Infinispan Java asosidagi ochiq manba tarqatilgan ichki xotira ma'lumotlar tarmog'i (Data Grid) yechimi hisoblanadi.
Qiziq tomoni shundaki, Keycloak o'zi ichki jihatdan allaqachon Infinispan'dan foydalanayotgan edi.
Ya'ni, alohida Redis yoki tashqi saqlash joyini qo'shmasdan Keycloak ichki kesh tuzilmasidan foydalanish imkonini berdi.
Bu tizimning murakkabligini sezilarli darajada kamaytirish afzalligi mavjud edi.
Loyihada KeycloakSession va InfinispanConnectionProvider dan foydalanib, maxsus keshga kirish tuzilmasini amalga oshirdik.
Amalga oshirish jarayoni uchta asosiy bosqichdan iborat.
Birinchi cache instansiyasini olish edi.
Keycloak tomonidan boshqariladigan Cache Manager-ga murojaat qilib, foydalanuvchilar uchun maxsus cache maydoni yaratildi.
Ikkinchisi holat qiymati (State Key) asosidagi ma'lumot saqlash tuzilmasi edi.
Tasdiqlash jarayonini boshlaganda noyob holat qiymatini (State Key) yaratib, uni kalit qiymati sifatida foydalanildi.
Va shifoxonani tasdiqlash jarayonida zarur bo'lgan DI qiymatini Value sifatida saqladik.
Ya'ni, tasdiqlash jarayonining o'rtasida haqiqiy DI qiymatini to'g'ridan-to'g'ri uzatish o'rniga faqat holat qiymatini (State Key) uzatish uchun tuzildi.
Uchinchi TTL (Time To Live) sozlamasi edi.
Sertifikatlash jarayoni ma'lumotlari vaqtincha kerak bo'lganligi sababli, xotira samaradorligini hisobga olish kerak edi.
Shu sababli, keshga saqlangan ma'lumotlar biroz vaqt o'tgach avtomatik ravishda o'chirilishi uchun TTL o'rnatildi.
Ushbu tuzilma tufayli foydalanuvchi tashqi autentifikatsiyadan so'ng yana Keycloak'ka qaytganida, holat qiymati (State Key) yordamida DI qiymatini xavfsiz tiklash imkoniyatiga ega bo'ldi.
Eng mashhur bo'lgan nuqtasi shundaki, tarqatilgan server muhitida ham bir xil ma'lumotlarni barqaror ravishda baham ko'rish mumkin edi.
Ya'ni, sertifikatlash jarayonida server tugunlari o'zgarganda ham sessiya yo'qolmasdan sertifikatlash oqimini davom ettirish mumkin edi.
Natijada Infinispan asosidagi tuzilma orqali shifoxona loyihasi talab qiladigan yuqori darajadagi autentifikatsiya barqarorligi va ma'lumotlar yaxlitligini ta'minlash imkoniyatiga ega bo'ldik.
6. Xulosa
Keycloak SPI asosida maxsuslashtirish oddiy plagin ishlab chiqarishdan ancha ko'proq tajriba bo'ldi.
Dastlab, oddiygina autentifikatsiya funksiyalarini qo'shishni rejalashtirgan edim, lekin aslida Keycloak dvigatelining ichki tuzilishi va autentifikatsiya oqimi mexanizmini chuqur tushunishim kerak edi.
Xususan Authentication Flow, AuthenticationFlowContext, SPI tuzilishi, Infinispan kesh arxitekturasi kabi sohalar oddiy sozlamalar bilan tushunib bo'lmaydigan joylarda edi.
Biroq, bunday tuzilmani bevosita tahlil qilib va muammolarni hal qilib borarkan, sertifikat platformasiga bo'lgan tushuncha yaxshi darajada oshdi.
Eng xizmatlarimizning o'ziga xos murakkab talablarini standart sertifikatlash platformasiga ishonchli tarzda joylashtirganimiz eng muhim jihat bo'ldi.
Xususan, shifoxona loyihasi oddiy xizmatlarga nisbatan ancha qat'iy sertifikatlash va xavfsizlik talablariga ega edi.
Bu oddiy kirish funksiyasi emas, balki haqiqiy shifoxona foydalanuvchilarini tasdiqlash, ko'p ijrochilik tuzilishi ichida huquqlarni dilimlash va tarqatilgan muhitda barqaror autentifikatsiya tajribasini ta'minlash kerak edi.
Bunday jarayon davomida oddiy funktsiyalarni amalga oshirishdan tashqari, tizim loyihalash va ma'lumotlar to'g'riligi, autentifikatsiya barqarorligini juda keng o'ylash imkoniyatiga ega bo'ldim.
Natijada, ushbu loyiha texnik jihatdan juda qiyin tajriba bo'ldi va dasturchi sifatida yanada o'sishimga yordam beradigan qimmatli loyiha bo'ldi.
Kelgusida ham sertifikatlash va huquqni boshqarish tizimini loyihalashda ushbu tajriba juda muhim mezon bo'ladi, deb o'ylayman.
joshua