İstənilən böyük şirkətdə və X5 Retail Group-da istisna deyil, inkişaf etdikcə istifadəçi icazəsi tələb edən layihələrin sayı artır. Vaxt keçdikcə istifadəçilərin bir proqramdan digərinə problemsiz keçidi tələb olunur və daha sonra tək Single-Sing-On (SSO) serverindən istifadə etmək zərurəti yaranır. Bəs AD və ya əlavə atributları olmayan digər identifikasiya provayderləri artıq müxtəlif layihələrdə istifadə edildikdə. “İdentifikasiya brokerləri” adlanan sistemlər sinfi köməyə gələcək. Ən funksionalı onun nümayəndələridir, məsələn, Keycloak, Gravitee Access Management və s. Çox vaxt istifadə halları fərqli ola bilər: maşınla qarşılıqlı əlaqə, istifadəçinin iştirakı və s. Həll bütün tələbləri bir yerdə birləşdirə bilən çevik və miqyaslı funksionallığı dəstəkləməlidir, və bu cür həllər üçün şirkətimizin indi bir göstərici brokeri var - Keycloak.
Keycloak RedHat tərəfindən idarə olunan açıq mənbəli şəxsiyyət və girişə nəzarət məhsuludur. SSO - RH-SSO istifadə edən şirkətin məhsulları üçün əsasdır.
Əsas anlayışlar
Həll və yanaşmalarla məşğul olmağa başlamazdan əvvəl proseslərin şərtləri və ardıcıllığı barədə qərar verməlisiniz:
Təsdiqləmə subyektin onun identifikatoru ilə tanınması prosedurudur (başqa sözlə, bu adın, loqin və ya nömrənin tərifidir).
İdentifikasiyası - bu autentifikasiya prosedurudur (istifadəçi parolla yoxlanılır, məktub elektron imza ilə yoxlanılır və s.)
Icazə - bu, resursa (məsələn, e-poçta) girişin təmin edilməsidir.
Identity Broker Keycloak
açar paltarı mikroservis memarlıq nümunələrinin istifadə oluna biləcəyi İS-də istifadə üçün nəzərdə tutulmuş açıq mənbəli şəxsiyyət və giriş idarəetmə həllidir.
Keycloak tək giriş (SSO), vasitəçi şəxsiyyət və sosial giriş, istifadəçi federasiyası, müştəri adapterləri, admin konsolu və hesab idarəetmə konsolu kimi xüsusiyyətləri təklif edir.
Keycloak tərəfindən dəstəklənən əsas funksionallıq:
- Brauzer proqramları üçün Tək Giriş və Tək Çıxış.
- OpenID/OAuth 2.0/SAML üçün dəstək.
- Identity Brokering - xarici OpenID Connect və ya SAML identifikasiya provayderlərindən istifadə edərək autentifikasiya.
- Sosial Giriş - İstifadəçinin identifikasiyası üçün Google, GitHub, Facebook, Twitter dəstəyi.
- İstifadəçi Federasiyası - LDAP və Active Directory serverlərindən və digər şəxsiyyət təminatçılarından istifadəçilərin sinxronizasiyası.
- Kerberos körpüsü - avtomatik istifadəçi autentifikasiyası üçün Kerberos serverindən istifadə.
- Admin Console - İnternet vasitəsilə parametrlərin və həll variantlarının vahid idarə edilməsi üçün.
- Hesab İdarəetmə Konsolu - istifadəçi profilinin özünü idarə etməsi üçün.
- Şirkətin korporativ şəxsiyyətinə əsaslanaraq həllin fərdiləşdirilməsi.
- 2FA Authentication - Google Authenticator və ya FreeOTP istifadə edərək TOTP/HOTP dəstəyi.
- Giriş axını - istifadəçinin özünü qeydiyyatı, parolun bərpası və sıfırlanması və digərləri mümkündür.
- Session İdarəetmə - administratorlar istifadəçi sessiyalarını bir nöqtədən idarə edə bilərlər.
- Token Mappers - istifadəçi atributlarını, rollarını və digər tələb olunan atributları tokenlərə bağlayır.
- Aləmdə, tətbiqdə və istifadəçilərdə çevik siyasət idarəsi.
- CORS Dəstəyi - Müştəri adapterlərinin daxili CORS dəstəyi var.
- Service Provider Interfaces (SPI) - Serverin müxtəlif aspektlərini fərdiləşdirməyə imkan verən çoxlu sayda SPI: autentifikasiya axınları, identifikasiya təminatçıları, protokol xəritələşdirilməsi və s.
- JavaScript proqramları üçün müştəri adapterləri, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- OpenID Connect Relying Party kitabxanasını və ya SAML 2.0 Service Provider Library-ni dəstəkləyən müxtəlif proqramlarla işləmək üçün dəstək.
- Pluginlərdən istifadə etməklə genişləndirilə bilər.
CI / CD prosesləri, həmçinin Keycloak-da idarəetmə proseslərinin avtomatlaşdırılması üçün REST API / JAVA API istifadə edilə bilər. Sənədlər elektron şəkildə mövcuddur:
REST API
Java API
Müəssisə Kimlik Təchizatçıları (Yerli)
İstifadəçi Federasiyası xidmətləri vasitəsilə istifadəçilərin autentifikasiyası imkanı.
Pass-through autentifikasiya da istifadə edilə bilər - əgər istifadəçilər Kerberos (LDAP və ya AD) ilə iş stansiyalarına qarşı autentifikasiya edərlərsə, o zaman onlar istifadəçi adlarını və parollarını yenidən daxil etmədən avtomatik olaraq Keycloak-da autentifikasiya oluna bilərlər.
İstifadəçilərin autentifikasiyası və əlavə avtorizasiyası üçün inkişaf mühitləri üçün ən uyğun olan əlaqəli DBMS-dən istifadə etmək mümkündür, çünki o, layihələrin ilkin mərhələlərində uzun parametrlər və inteqrasiyaları nəzərdə tutmur. Varsayılan olaraq, Keycloak parametrləri və istifadəçi məlumatlarını saxlamaq üçün daxili DBMS-dən istifadə edir.
Dəstəklənən DBMS-lərin siyahısı genişdir və daxildir: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle və s. İndiyə qədər ən çox sınaqdan keçirilmiş Oracle 12C Release1 RAC və MariaDB 3.12 üçün Galera 10.1.19 klasteridir.
Şəxsiyyət təminatçıları - sosial giriş
Sosial şəbəkələrdən girişdən istifadə etmək mümkündür. İstifadəçilərin autentifikasiyası imkanını aktivləşdirmək üçün Keycloack admin konsolundan istifadə edin. Tətbiq kodunda dəyişikliklər tələb olunmur və bu funksionallıq qutudan kənarda mövcuddur və layihənin istənilən mərhələsində aktivləşdirilə bilər.
İstifadəçinin autentifikasiyası üçün OpenID/SAML Identity provayderlərindən istifadə etmək mümkündür.
Keycloak-da OAuth2 istifadə edən tipik avtorizasiya ssenariləri
Avtorizasiya kodu axını - server tərəfi proqramlarla istifadə olunur. Tətbiqin mənbə kodu və müştəri məlumatlarının kənar şəxslər üçün əlçatmaz olduğu server proqramları üçün uyğun olduğu üçün avtorizasiya icazəsinin ən geniş yayılmış növlərindən biridir. Bu vəziyyətdə proses yönləndirməyə əsaslanır. Tətbiq istifadəçi agenti (istifadəçi-agent) ilə qarşılıqlı əlaqə qura bilməlidir, məsələn, veb-brauzer - istifadəçi agenti vasitəsilə yönləndirilmiş API icazə kodlarını almaq üçün.
gizli axın - mobil və ya veb proqramlar tərəfindən istifadə olunur (istifadəçinin cihazında işləyən proqramlar).
Gizli avtorizasiya icazə növü müştəri məxfiliyinə zəmanət verilə bilməyən mobil və veb proqramlar tərəfindən istifadə olunur. Gizli icazə növü həmçinin istifadəçi agentinin yönləndirməsindən istifadə edir, bununla da giriş nişanı tətbiqdə sonrakı istifadə üçün istifadəçi agentinə ötürülür. Bu, tokeni istifadəçi və istifadəçinin cihazındakı digər proqramlar üçün əlçatan edir. Bu cür avtorizasiya icazəsi tətbiqin şəxsiyyətini təsdiqləmir və prosesin özü yönləndirmə URL-inə (əvvəllər xidmətdə qeydiyyatdan keçmiş) əsaslanır.
Implicit Flow giriş tokenini yeniləmək üçün işarələri dəstəkləmir.
Müştəri Etibarnamələri Flow axını — proqram API-yə daxil olduqda istifadə olunur. Bu cür avtorizasiya icazəsi adətən istifadəçinin dərhal qarşılıqlı əlaqəsi olmadan arxa planda yerinə yetirilməli olan server-server qarşılıqlı əlaqəsi üçün istifadə olunur. Müştəri etimadnamələrinin qrant axını veb xidmətinə (məxfi müştəri) başqa bir veb xidmətə zəng edərkən autentifikasiya etmək üçün istifadəçini təqlid etmək əvəzinə öz etimadnaməsini istifadə etməyə imkan verir. Daha yüksək təhlükəsizlik səviyyəsi üçün zəng edən xidmətin etimadnamə kimi sertifikatdan (ortaq sirr əvəzinə) istifadə etməsi mümkündür.
OAuth2 spesifikasiyası burada təsvir edilmişdir
JWT token və onun üstünlükləri
JWT (JSON Web Token) açıq standartdır () JSON obyekti kimi tərəflər arasında məlumatı təhlükəsiz ötürmək üçün yığcam və müstəqil yolu müəyyən edir.
Standarta əsasən, token nöqtələrlə ayrılmış baza-64 formatında üç hissədən ibarətdir. Birinci hissə başlıq adlanır ki, burada işarənin növü və rəqəmsal imzanın əldə edilməsi üçün hash alqoritminin adı var. İkinci hissə əsas məlumatları (istifadəçi, atributlar və s.) saxlayır. Üçüncü hissə isə rəqəmsal imzadır.
. .
Heç vaxt DB-də token saxlamayın. Etibarlı nişan parola bərabər olduğundan, nişanı saxlamaq parolu aydın mətndə saxlamaq kimidir.
Giriş nişanı sahibinə təhlükəsiz server resurslarına giriş imkanı verən bir işarədir. Onun adətən qısa ömrü var və token tələb edən tərəfin IP ünvanı kimi əlavə məlumatları daşıya bilər.
Tokeni yeniləyin müştərilərə ömürlük müddəti bitdikdən sonra yeni giriş tokenləri tələb etməyə imkan verən əlamətdir. Bu tokenlər adətən uzun müddətə verilir.
Mikroservis arxitekturasında istifadənin əsas üstünlükləri:
- Birdəfəlik autentifikasiya vasitəsilə müxtəlif proqram və xidmətlərə daxil olmaq imkanı.
- İstifadəçi profilində bir sıra tələb olunan atributlar olmadıqda, avtomatlaşdırılmış və anında daxil olmaqla, faydalı yükə əlavə edilə bilən məlumatlarla zənginləşdirmək mümkündür.
- Aktiv seanslar haqqında məlumat saxlamağa ehtiyac yoxdur, server tətbiqi yalnız imzanı yoxlamalıdır.
- Yükdə əlavə atributlar vasitəsilə daha çevik giriş nəzarəti.
- Başlıq və faydalı yük üçün işarə imzasının istifadəsi bütövlükdə həllin təhlükəsizliyini artırır.
JWT token - kompozisiya
Başlıq - defolt olaraq, başlıq yalnız işarənin növünü və şifrələmə üçün istifadə olunan alqoritmi ehtiva edir.
Tokenin növü "typ" düyməsində saxlanılır. JWT-də "növ" düyməsi nəzərə alınmır. Əgər "typ" açarı varsa, bu obyektin JSON Veb Tokeni olduğunu göstərmək üçün onun dəyəri JWT olmalıdır.
İkinci açar "alg" nişanı şifrələmək üçün istifadə olunan alqoritmi müəyyənləşdirir. Defolt olaraq HS256-a təyin edilməlidir. Başlıq base64-də kodlaşdırılıb.
{ "alg": "HS256", "növ": "JWT"}
faydalı yük (məzmun) - faydalı yük yoxlanılması lazım olan hər hansı məlumatı saxlayır. Faydalı yükün hər bir açarı "iddia" kimi tanınır. Məsələn, proqrama yalnız dəvətnamə ilə daxil ola bilərsiniz (qapalı promo). Biz kimisə iştiraka dəvət etmək istədikdə ona dəvət məktubu göndəririk. E-poçt ünvanının dəvəti qəbul edən şəxsə aid olduğunu yoxlamaq vacibdir, ona görə də bu ünvanı faydalı yükə daxil edəcəyik, bunun üçün onu "e-poçt" açarında saxlayırıq.
{ "e-poçt": "[e-poçt qorunur]"}
Yükündəki açarlar ixtiyari ola bilər. Bununla belə, qorunan bir neçə var:
- iss (Emitent) - Tokenin göndərildiyi tətbiqi müəyyən edir.
- sub (Mövzu) - tokenin mövzusunu müəyyən edir.
- aud (Audience) bu tokenin alıcılarının siyahısı olan hərflərə həssas sətirlər və ya URI massividir. Qəbul edən tərəf verilmiş açarla JWT aldıqda, alıcılarda özünün olub-olmadığını yoxlamalıdır - əks halda tokenə məhəl qoymamalıdır.
- exp (Expiration Time) - Tokenin nə vaxt bitdiyini göstərir. JWT standartı onun bütün tətbiqlərinin vaxtı keçmiş tokenləri rədd etməsini tələb edir. Exp açarı unix formatında vaxt damğası olmalıdır.
- nbf (Əvvəlki deyil) tokenin etibarlı olduğu anı təyin edən unix formatında vaxtdır.
- iat (Issued At) - Bu açar tokenin buraxıldığı vaxtı əks etdirir və JWT-nin yaşını müəyyən etmək üçün istifadə edilə bilər. iat açarı unix formatında vaxt damğası olmalıdır.
- Jti (JWT ID) — bu işarənin unikal identifikatorunu təyin edən sətir, hərflərə həssasdır.
Faydalı yükün şifrələnmiş formada ötürülmədiyini başa düşmək vacibdir (baxmayaraq ki, tokenlər yuvalana bilər və sonra şifrələnmiş məlumatları ötürmək mümkündür). Buna görə də heç bir gizli məlumat saxlaya bilməz. Başlıq kimi, faydalı yük də base64 kodludur.
Imza - başlığımız və yükümüz olanda imzanı hesablaya bilərik.
Base64 kodlu: başlıq və faydalı yük götürülür, onlar nöqtə vasitəsilə sətirdə birləşdirilir. Sonra bu sətir və gizli açar başlıqda göstərilən şifrələmə alqoritminə daxil edilir (“alg” açarı). Açar istənilən simli ola bilər. Daha uzun simlərə ən çox üstünlük veriləcək, çünki onu götürmək daha uzun sürəcəkdir.
{"alg":"RSA1_5","faydalı yük":"A128CBC-HS256"}
Keycloak Failover Cluster Arxitekturasının qurulması
Bütün layihələr üçün vahid klasterdən istifadə edərkən SSO həlli üçün artan tələblər var. Layihələrin sayı az olduqda, bu tələblər bütün layihələr üçün o qədər də nəzərə çarpmır, lakin istifadəçilərin və inteqrasiyaların sayının artması ilə mövcudluq və performans tələbləri artır.
Tək SSO uğursuzluq riskinin artırılması həll arxitekturasına və lazımsız komponentlər üçün istifadə olunan metodlara tələbləri artırır və çox sıx SLA-ya gətirib çıxarır. Bu baxımdan, daha tez-tez həllərin hazırlanması və ya tətbiqinin ilkin mərhələlərində layihələrin öz qüsursuz infrastrukturu olur. İnkişaf irəlilədikcə inkişaf və miqyas üçün imkanlar yaratmaq tələb olunur. Konteyner virtualizasiyasından və ya hibrid yanaşmadan istifadə edərək uğursuzluq klasterini qurmaq ən çevikdir.
Aktiv/Aktiv və Aktiv/Passiv klaster rejimlərində işləmək üçün əlaqəli verilənlər bazasında məlumatların ardıcıllığını təmin etmək tələb olunur - hər iki verilənlər bazası qovşağı müxtəlif geo-paylanmış məlumat mərkəzləri arasında sinxron şəkildə təkrarlanmalıdır.
Arızaya davamlı quraşdırmanın ən sadə nümunəsi.
Tək klasterdən istifadənin üstünlükləri nələrdir:
- Yüksək əlçatanlıq və performans.
- İş rejimləri üçün dəstək: Aktiv / Aktiv, Aktiv / Passiv.
- Dinamik miqyaslandırma qabiliyyəti - konteyner virtualizasiyasından istifadə edərkən.
- Mərkəzləşdirilmiş idarəetmə və monitorinq imkanı.
- Layihələrdə istifadəçilərin identifikasiyası/autentifikasiyası/avtorizasiyası üçün vahid yanaşma.
- İstifadəçinin iştirakı olmadan müxtəlif layihələr arasında daha şəffaf qarşılıqlı əlaqə.
- Müxtəlif layihələrdə JWT tokenindən təkrar istifadə etmək imkanı.
- Tək güvən nöqtəsi.
- Mikroservislər/konteyner virtualizasiyasından istifadə edərək layihələrin daha sürətli işə salınması (əlavə komponentləri qaldırmağa və konfiqurasiya etməyə ehtiyac yoxdur).
- Satıcıdan kommersiya dəstəyi almaq mümkündür.
Klaster planlaşdırarkən nələrə diqqət etməli
DBMS
Keycloak saxlamaq üçün verilənlər bazası idarəetmə sistemindən istifadə edir: reallıqlar, müştərilər, istifadəçilər və s.
DBMS-in geniş spektri dəstəklənir: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak öz daxili relational verilənlər bazası ilə gəlir. Yüklənməmiş mühitlər üçün istifadə etmək tövsiyə olunur - məsələn, inkişaf mühitləri.
Aktiv/Aktiv və Aktiv/Passiv klaster rejimlərində işləmək üçün əlaqəli verilənlər bazasında verilənlərin ardıcıllığı tələb olunur və hər iki verilənlər bazası klaster qovşağı məlumat mərkəzləri arasında sinxron surətdə təkrarlanır.
Paylanmış keş (Infinspan)
Klasterin düzgün işləməsi üçün JBoss Data Grid istifadə edərək aşağıdakı növ keşlərin əlavə sinxronizasiyası tələb olunur:
Doğrulama sessiyaları - müəyyən istifadəçinin autentifikasiyası zamanı məlumatların saxlanması üçün istifadə olunur. Bu keşdən gələn sorğular adətən tətbiqi deyil, yalnız brauzeri və Keycloak serverini əhatə edir.
Fəaliyyət tokenləri istifadəçinin hərəkəti asinxron şəkildə təsdiqləməli olduğu ssenarilər üçün istifadə olunur (e-poçt vasitəsilə). Məsələn, parolun unudulması zamanı, actionTokens Infinispan keşi artıq istifadə edilmiş əlaqəli fəaliyyət nişanları haqqında metadatanın izlənilməsi üçün istifadə olunur, ona görə də onu təkrar istifadə etmək olmaz.
Davamlı məlumatların keşləşdirilməsi və etibarsızlaşdırılması - verilənlər bazasına lazımsız sorğuların qarşısını almaq üçün davamlı məlumatları keş etmək üçün istifadə olunur. Hər hansı Keycloak server məlumatları yenilədikdə, bütün məlumat mərkəzlərindəki bütün digər Keycloak serverləri bu barədə bilməlidir.
İş - Yalnız klaster qovşaqları və məlumat mərkəzləri arasında etibarsız mesajlar göndərmək üçün istifadə olunur.
İstifadəçi sessiyaları - istifadəçinin brauzer seansı müddətində etibarlı olan istifadəçi seansları haqqında məlumatları saxlamaq üçün istifadə olunur. Keş son istifadəçidən və tətbiqdən HTTP sorğularını emal etməlidir.
Qəddar qüvvədən qorunma - uğursuz girişlər haqqında məlumatları izləmək üçün istifadə olunur.
Yük balansı
Yük balanslaşdırıcı açar gizlətmək üçün tək giriş nöqtəsidir və yapışqan seansları dəstəkləməlidir.
Tətbiq serverləri
Onlar komponentlərin bir-biri ilə qarşılıqlı əlaqəsinə nəzarət etmək üçün istifadə olunur və mövcud avtomatlaşdırma vasitələri və infrastrukturun avtomatlaşdırılması vasitələrinin dinamik miqyasından istifadə edərək virtuallaşdırıla və ya konteynerləşdirilə bilər. OpenShift, Kubernates, Rancher-də ən çox yayılmış yerləşdirmə ssenariləri.
Bununla birinci hissə - nəzəri hissə yekunlaşır. Növbəti məqalələr seriyasında müxtəlif şəxsiyyət təminatçıları ilə inteqrasiya nümunələri və parametrlər nümunələri təhlil ediləcəkdir.
Mənbə: www.habr.com