1. Token Almashishning Asosiy Tushunchasi
Mikroservislar arxitekturasi (MSA) muhitida, bir nechta xizmatlar o'rtasida vakolatlarni topshirish yoki tokenlarni qayta berish zarur bo'lganda, Keycloak tomonidan taqdim etilgan token almashish funksiyasi juda foydali yechimdir. Ushbu texnologiya tasdiqlangan mijozga mavjud tokenni taqdim etishga imkon beradi, bu Keycloak tomonidan tasdiqlanadi va tegishli vakolat va manzil uchun yangi token bilan almashtiriladi. Bu xizmatlar o'rtasidagi ishonch munosabatlarini aniq belgilaydi va vakolat doirasini nazorat qiladi, bu esa korporativ xavfsizlikning asosiy poydevoriga aylanishda muhim ahamiyatga ega.
2. Integratsiya Talablari va Taqlidni Qo'llab-Quvvatlash
Yaqqol bir loyiha davomida uchinchi tomon platformalarida allaqachon autentifikatsiyadan o'tgan foydalanuvchilarga bizning xizmatlarimizga kirish uchun kirish oynasi yoki qo'shimcha kirish jarayonisiz imkon berish talabi bo'ldi. Vazifa foydalanuvchilarni ikki marta kirishdan saqlash uchun qopqoqsiz UX ni amalga oshirish edi.
Aynan standart Keycloak V2 dvigatelidan foydalanishga harakat qilsak ham, texnik cheklovlarga duch keldik. Standart spetsifikatsiya tashqi xizmatning original kirish ma'lumotlarini (asl token) talab qiladi, lekin hamkor xavfsizlik siyosati tufayli o'z tokenlarini baham ko'ra olmadi va faqat 'foydalanuvchi unik ID (identifikator)'ni o'tkazdi.
Biz faqat identifikatsiya ma'lumotlarini uzatishga majbur bo'lganimiz sababli, standart dvigatelni joriy etish imkoni bo'lmadi. Shuning uchun, qo'shimcha maxsus modullarni ishlab chiqmasdan talablarga javob berish uchun, faqat orqa tomon ma'lumotlari va foydalanuvchi ID satrlari bilan token berishga ruxsat beruvchi eskirgan spesifikatsiya (V1 To'g'ridan-to'g'ri Taqlid) usulini tanladik. Biz ichki infratuzilmani himoya qilish uchun oldida 'xavfsizlik proxy (Bridge Gateway)' joylashtiradigan tuzilma yaratdik va ekran uchun tokenlarni yetkazish uchun orqa kanallar orqali tokenlarni qabul qildik.
3. Keycloak Boshqaruvi: Mijozlarni Ulash
Token almashishni xavfsiz ravishda berish uchun Keycloak konsolida so'rovchi va maqsadli mijozlar o'rtasida aniq ishonch munosabatlari aniqlanishi kerak.
-
Tashqi Xizmat uchun Mijoz (So'rovchi):Master sir kalitini ichki tarzda yashirish uchun Mijoz autentifikatsiyasini Faolga (Confidential) o'rnating. Eskirgan V1 mexanizmini qo'llash uchun, server qatlamida eski batafsil boshqaruv vakolatini (FGAP:v1) faollashtiring.
-
Ichki MSA uchun Mijoz (Maqsad):Avtorizatsiya va ekran bilan shug'ullanadigan mijozning Ruxsatlar menyusida token-almashishni faollashtiring. Faqat tashqi proxy mijoziga delegat berish va tokenlarni almashishga ruxsat beradigan siyosat yarating.
4. Orqa tomonni Ijro Etish: Token So'rovi Spesifikatsiyasi
Proxy server (Spring Boot) tashqi tizimlardan kelgan so'rovlarni tasdiqlaydi va Keycloak endpointini xavfsiz chaqirish uchun ko'prik kodini bajaraydi. Eskirgan V1 standarti bo'yicha API yuk ko'tarish spetsifikatsiyasi quyidagicha.
-
Endpoint URL: POST /realms/{realm-name}/protocol/openid-connect/token
-
Header spetsifikatsiyasi: Content-Type: application/x-www-form-urlencoded, Authorization: Basic [Base64(ID:Secret)]
Token berish uchun zaruriy parametrlar
|
Parametr nomi |
Konfiguratsiya qiymatlari va misollar |
Tavsif |
|---|---|---|
|
grant_type |
urn:ietf:params:oauth:grant-type:token-exchange |
Protokol spetsifikatsiyasi |
|
requested_subject |
user_internal_idx_01 |
Token berilayotgan ichki foydalanuvchining noyob IDsi |
|
requested_token_type |
urn:ietf:params:oauth:token-type:access_token |
Aniq kirish tokeni so‘rovi |
|
audience |
internal-msa-core |
Keraksiz ruxsatnomalarni kamaytirish orqali pastki o‘lchamlashni ishga tushiradi |
Agar Keycloak validatsiyasi muvaffaqiyatli o‘tsa, access_token javob ma'lumotlaridan olinadi. Ushbu token faqat foydalanuvchining ichki biznes rollarini (masalan, ROLE_USER) qo‘shadi va proksi uni xizmat ko‘rsatuvchi tashqi xizmatdan o‘tib, foydalanuvchi brauzeriga yuklaydi va yo‘naltirishni amalga oshiradi.
5. Ommabop xatolar va yechimlar
Bu haqiqiy operatsiya va joylashtirish bosqichlarida uchraydigan uchta asosiy ishga tushirish xatolarini boshqarish uchun qo‘llanmadir.
-
HTTP 404 Topilmadi xatosi:Eski hujjatga murojaat qilinganda va endpoint manzilida /auth yo‘lini kiritganda yuzaga keladi. So‘nggi versiyada /auth standart kontekst yo‘lidan olib tashlangan, shuning uchun u chiqarib tashlanishi kerak.
-
invalid_client xatosi:So‘rovni yuborayotgan proksi klientning sozlamalarida token almashtirish spetsifikasiga tegishli imkoniyat yoqilmaganda yuzaga keladi, shuning uchun konsoldagi tegishli yoqish tugmasini yana bir bor tekshirish kerak.
-
403 Ta'qiqlangan / ruxsat berilmagan xatosi:Klientdan klientga ishonch siyosati yo‘qolganda yuzaga keladi. So‘rov yuborayotgan klient, maqsadli klientning Ruxsatlar menyusida siyosatchilar to‘plamida ro‘yxatdan o‘tganmi-yo‘qligini tekshirish kerak.
6. Meros (V1) usulining cheklovlari va amaliy murosalar
Ushbu loyihada meros spetsifikasining (V1 Direct Naked Impersonation) o‘rniga eng so‘nggi V2 Standart dvigatelidan foydalanish, tashqi integratsiya muhitlarining cheklovlarini yengish uchun qasddan arxitektura tanlovi edi.
Keycloak V2 standart dvigateli almashish uchun asl tokenni taqdim etishni majburiy belgilash sifatida talab qiladi. Biroq, ishtirok etayotgan tashqi hamkor o'z xavfsizlik siyosatlari tufayli foydalanuvchi sessiyasi tokenlarini baham ko'ra olmadi va faqat 'unikal foydalanuvchi ID'sini' taqdim etish imkonini beruvchi texnik cheklov mavjud edi. Asl token bo'lmagan holatda, foydalanuvchi ID'siga asoslangan token chiqarishni ta'minlaydigan eski V1 standart barcha talabni o'z vaqtida 'qo'shimcha kirish jarayonini istisno qilish' talabi bilan amalga oshirish uchun eng amaliy variant edi, alohida shifrlash tokeni ishlab chiqarish tizimini proxy serverga qo'shmasdan.
Eski spetsifikatsiyaning potentsial xavflari infratuzilma qatlamining ko'p qatlamli mudofaa tizimi tomonidan qoplandi. Server tarmog'i (M2M) va foydalanuvchi interfeysi tarmog'i (UI) ruxsatlari qat'iy ikkilamchi izolyatsiyaga ega edi va brauzerda ochiq tokenlarning amal qilish muddati 3 dan 5 daqiqagacha qisqa muddatli tokenlar bilan cheklangan edi, bu esa o'g'irlik xavfini nazorat qilishga yordam beradi. Keycloak dvigatelidagi yangilanishlar tufayli standart V2 tizimiga o'tish vazifasi kelajakda mavjud bo'lishiga qaramay, cheklangan resurslar doirasida tashqi tomonlar bilan integratsiya spetsifikatsiyalariga tegmasdan biznes maqsadlariga erishish uchun eng haqiqiy muhandislik kompromisi edi.
7. Xulosa
Ushbu loyiha B2B integratsiyasi davomida xavfsizlik va foydalanuvchi qulayligini ta'minlash qanchalik muammoli ekanligini qayta tasdiqlash sifatida xizmat qildi. Tashqi infratuzilma cheklovlari ostida eng yaxshi amaliy arxitektura ko'rib chiqish jarayoni o'z-o'zidan muhim aktivga aylandi. Ushbu integratsiya holati mikroservislar muhitida Keycloak asosida autentifikatsiya infratuzilmasini ko'rib chiqayotganlar uchun amaliy ma'lumot bo'ladi, deb umid qilaman.
Manbalar
https://www.keycloak.org/securing-apps/token-exchange
oshua