ДЗС за микросервис архитектура. Ние користиме Keycloak. Дел 1

Во која било голема компанија, а X5 Retail Group не е исклучок, бидејќи се развива, бројот на проекти за кои е потребно овластување од корисникот се зголемува. Со текот на времето, потребна е беспрекорна транзиција на корисниците од една апликација во друга, а потоа се јавува потреба да се користи единствен сервер за едно пеење (SSO). Но, што е со кога давателите на идентитети како АД или други кои немаат дополнителни атрибути веќе се користат во различни проекти. Класа системи наречени „брокери за идентификација“ ќе дојдат на помош. Најфункционални се неговите претставници, како што се Keycloak, Gravitee Access Management итн. Најчесто, случаите на употреба можат да бидат различни: машинска интеракција, учество на корисникот итн. Решението мора да поддржува флексибилна и скалабилна функционалност која може да ги комбинира сите барања во едно. и такви решенија нашата компанија сега има индикациски брокер - Keycloak.

Keycloak е производ со отворен код за идентитет и контрола на пристап кој го одржува RedHat. Тоа е основа за производите на компанијата кои користат ДЗС - RH-SSO.

Основни концепти

Пред да започнете да ги разбирате решенијата и пристапите, треба да ги дефинирате термините и редоследот на процесите:

Идентификација е постапка за препознавање на субјектот по неговиот идентификатор (со други зборови, ова е одредување име, најава или број).

Автентикација – ова е процедура за автентикација (корисникот се проверува со лозинка, писмото се проверува со електронски потпис итн.)

Овластување - ова е обезбедување пристап до ресурс (на пример, до е-пошта).

Клучник за брокер за идентитет

клуч наметка е решение за управување со идентитет и пристап со отворен код, дизајнирано за употреба во IS каде што може да се користат шеми на микросервис архитектура.

Keycloak нуди функции како што се едно најавување (SSO), идентитет со посредство и социјално најавување, федерација на корисници, адаптери за клиенти, административна конзола и конзола за управување со сметки.

Основна функционалност поддржана од Keycloak:

• Едноставно најавување и едно одјавување за апликации на прелистувачот.
• Поддршка за OpenID/OAuth 2.0/SAML.
• Посредување за идентитет – автентикација со помош на надворешни OpenID Connect или SAML провајдери на идентитет.
• Социјално најавување - Google, GitHub, Facebook, Twitter поддршка за идентификација на корисникот.
• Корисничка федерација - синхронизација на корисници од сервери LDAP и Active Directory и други даватели на идентитети.
• Kerberos bridge – употреба на Kerberos сервер за автоматска автентикација на корисникот.
• Административна конзола - за унифицирано управување со поставките и опциите за решенија преку Интернет.
• Конзола за управување со сметки - за самоуправување со корисничкиот профил.
• Прилагодување на решението врз основа на корпоративниот идентитет на компанијата.
• 2FA автентикација – TOTP/HOTP поддршка со користење на Google Authenticator или FreeOTP.
• Текови за најава - можна е саморегистрација на корисникот, враќање и ресетирање лозинка и други.
• Управување со сесии - администраторите можат да управуваат со сесиите на корисниците од една точка.
• Mappers на токени – врзување на корисничките атрибути, улоги и други потребни атрибути во токени.
• Флексибилно управување со политиката преку областа, апликацијата и корисниците.
• Поддршка на CORS - Клиентските адаптери имаат вградена поддршка за CORS.
• Интерфејси на добавувачи на услуги (SPI) - голем број на SPI кои ви дозволуваат да приспособите различни аспекти на серверот: текови на автентикација, даватели на идентитети, мапирање на протоколи и многу повеќе.
• Клиент адаптери за JavaScript апликации, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
• Поддршка за работа со различни апликации кои ја поддржуваат библиотеката на засегнатата страна на OpenID Connect или библиотеката со давател на услуги SAML 2.0.
• Може да се прошири со помош на приклучоци.

За процесите на CI/CD, како и за автоматизација на процесите на управување во Keycloak, може да се користи REST API/JAVA API. Документацијата е достапна во електронска форма:

ОСТАНАТОТО API https://www.keycloak.org/docs-api/8.0/rest-api/index.html
Java API https://www.keycloak.org/docs-api/8.0/javadocs/index.html

Даватели на идентитет на претпријатие (во простор)

Можност за автентикација на корисникот преку услугите на Корисничката федерација.

Може да се користи и автентикација преку премин - ако корисниците автентицираат на работните станици со Kerberos (LDAP или AD), тогаш тие можат автоматски да се автентицираат на Keycloak без да мора повторно да ги внесуваат нивното корисничко име и лозинка.

За автентикација и понатамошно овластување на корисниците, можно е да се користи релациона DBMS, што е најприменливо за развојни средини, бидејќи не повлекува долги поставки и интеграции во раните фази на проектите. Стандардно, Keycloak користи вграден DBMS за складирање на поставките и корисничките податоци.

Листата на поддржани DBMS е обемна и вклучува: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle и други. Најтестирани досега се Oracle 12C Release1 RAC и Galera 3.12 кластерот за MariaDB 10.1.19.

Даватели на идентитет - социјално најавување

Можно е да се користи најавување од социјалните мрежи. За да ја овозможите можноста за автентикација на корисниците, користете ја административната конзола Keycloack. Не се потребни промени во кодот на апликацијата и оваа функционалност е достапна надвор од кутијата и може да се активира во која било фаза од проектот.

За автентикација на корисниците, можно е да се користат провајдери на OpenID/SAML Identity.

Типични сценарија за авторизација со користење на OAuth2 во Keycloak

Тек на код за овластување - се користи со апликации од страна на серверот. Еден од најчестите типови на дозволи за авторизација бидејќи е добро прилагоден за апликации од страна на серверот каде што изворниот код на апликацијата и податоците на клиентот не се достапни за други. Процесот во овој случај се заснова на пренасочување. Апликацијата мора да може да комуницира со кориснички агент (кориснички агент), како што е веб-прелистувач, за да прима кодови за авторизација на API проследени преку корисничкиот агент.

Имплицитен тек - се користи од мобилни или веб-апликации (апликации што работат на уредот на корисникот).

Имплицитниот тип на дозвола за авторизација се користи од мобилни и веб-апликации каде што не може да се гарантира доверливоста на клиентот. Имплицитниот тип на дозвола користи и пренасочување на кориснички агент, при што токенот за пристап се пренесува на корисничкиот агент за понатамошна употреба во апликацијата. Ова го прави токенот достапен за корисникот и другите апликации на уредот на корисникот. Овој тип на дозвола за авторизација не го потврдува идентитетот на апликацијата, а самиот процес се потпира на URL-адреса за пренасочување (претходно регистрирана во услугата).

Имплицитниот тек не поддржува токени за освежување на токен за пристап.

Тек на грантови за акредитиви на клиентите — се користи кога апликацијата пристапува до API. Овој тип на дозвола за овластување обично се користи за интеракции од сервер до сервер што мора да се појават во заднина без непосредна интеракција со корисникот. Протокот на грантови за акредитиви на клиентот дозволува веб-услуга (доверлив клиент) да ги користи сопствените ингеренции наместо да го имитира корисникот за автентикација кога повикува друга веб-услуга. За повисоко ниво на безбедност, можно е услугата за повикување да користи сертификат (наместо споделена тајна) како ингеренции.

Спецификацијата OAuth2 е опишана во
RFC-6749
RFC-8252
RFC-6819

JWT токен и неговите придобивки

JWT (JSON Web Token) е отворен стандард (https://tools.ietf.org/html/rfc7519) што дефинира компактен и самостоен начин за безбедно пренесување информации помеѓу страните како JSON објект.

Според стандардот, токенот се состои од три дела во формат база-64, одделени со точки. Првиот дел се нарекува заглавие, кој го содржи типот на токен и името на алгоритмот за хаш за добивање дигитален потпис. Вториот дел ги складира основните информации (корисник, атрибути итн.). Третиот дел е дигитален потпис.

. .
Никогаш не чувајте го токенот во вашата база на податоци. Бидејќи важечкиот токен е еквивалентен на лозинка, складирањето токен е исто како и складирањето лозинка во јасен текст.
Токен за пристап е токен што му овозможува на сопственикот пристап до заштитените ресурси на серверот. Обично има краток век на траење и може да носи дополнителни информации, како што е IP адресата на страната што го бара токенот.

Освежи токен е токен кој им овозможува на клиентите да бараат нови токени за пристап откако ќе им истече животниот век. Овие токени обично се издаваат на долг временски период.

Главните предности на користење во архитектурата на микросервис:

• Можност за пристап до различни апликации и услуги преку еднократна автентикација.
• Во отсуство на голем број потребни атрибути во корисничкиот профил, можно е да се збогатат со податоци што може да се додадат на товарот, вклучително и автоматски и во лет.
• Нема потреба да се складираат информации за активните сесии; серверската апликација треба само да го потврди потписот.
• Пофлексибилна контрола на пристап преку дополнителни атрибути во товарот.
• Користењето на токен потпис за заглавието и товарот ја зголемува безбедноста на целокупното решение.

JWT токен - состав

Титула - стандардно, заглавието го содржи само типот на токен и алгоритмот што се користи за шифрирање.

Типот на токенот е зачуван во копчето „typ“. Копчето „тип“ се игнорира во JWT. Ако е присутен клучот „typ“, неговата вредност мора да биде JWT за да означи дека овој објект е JSON Web Token.

Вториот клуч „alg“ го дефинира алгоритмот што се користи за шифрирање на токенот. Стандардно треба да се постави на HS256. Заглавието е шифрирано во base64.

{ "alg": "HS256", "typ": "JWT"}
носивост (содржина) — товарот ги складира сите информации што треба да се проверат. Секој клуч во товарот е познат како „побарување“. На пример, можете да ја внесете апликацијата само со покана (затворена промоција). Кога сакаме да поканиме некого да учествува, му испраќаме е-пошта за покана. Важно е да потврдите дека адресата на е-пошта му припаѓа на лицето кое ја прифаќа поканата, така што ќе ја вклучиме оваа адреса во товарот со складирање во клучот „email“.

{ "email": "[заштитена по е-пошта]"}

Клучевите во носивоста може да бидат произволни. Сепак, има неколку резервирани:

• iss (Издавач) - Ја идентификува апликацијата од која се испраќа токенот.
• под (Subject) - го дефинира предметот на токенот.
• aud (Публика) е низа низи или URI чувствителни на големи букви што е листа на приматели на овој токен. Кога примачката страна добива JWT со дадениот клуч, таа мора да провери дали е присуство на себе во примачите - во спротивно игнорирајте го токенот.
• exp (Време на истекување) - Покажува кога истекува токенот. Стандардот JWT бара сите имплементации да отфрлаат истечени токени. Клучот Exp мора да биде временски печат во формат Unix.
• nbf (Not Before) е време во Unix формат што го одредува моментот кога токенот станува валиден.
• iat (Issued at) - Овој клуч го претставува времето на издавање на токенот и може да се користи за да се одреди староста на JWT. Копчето iat мора да биде временски печат во формат Unix.
• Jti (JWT ID) е низа што дефинира единствен идентификатор чувствителен на големи букви за овој токен.

Важно е да се разбере дека товарот не се пренесува шифрирано (иако токените може да се вгнездуваат и потоа е можно да се пренесат шифрирани податоци). Затоа, не можете да складирате никакви тајни информации во него. Како и заглавието, товарот е кодиран во base64.
Потпис - кога имаме наслов и носивост, можеме да го пресметаме потписот.

Кодирано со Base64: се земаат насловот и носивоста, тие се комбинираат во низа низ точка. Потоа оваа низа и тајниот клуч се внесуваат во алгоритмот за шифрирање наведен во заглавието (клуч "alg"). Клучот може да биде која било низа. Најмногу се претпочитаат подолги жици бидејќи ќе биде потребно подолго време да се подигнат.

{"alg":"RSA1_5", "payload":"A128CBC-HS256"}

Изградба на Архитектура на кластер за неуспех на Keycloak

Кога се користи еден кластер за сите проекти, има зголемени барања за решение на ДЗС. Кога бројот на проекти е мал, овие барања не се толку забележливи за сите проекти, меѓутоа, со зголемување на бројот на корисници и интеграции, барањата за достапност и перформанси се зголемуваат.

Зголемувањето на ризикот од единечен неуспех на ДЗС ги зголемува барањата за архитектурата на решението и методите што се користат за вишок компоненти и доведува до многу тесна SLA. Во таа насока, почесто во текот на развојот или раните фази на имплементација на решенијата, проектите имаат своја инфраструктура која не поднесува грешки. Како што напредува развојот, потребно е да се утврдат можностите за развој и скалирање. Најфлексибилно е да се изгради кластер за попуштање користејќи виртуелизација на контејнери или хибриден пристап.

За да се работи во режимите на кластерот Активно/Активно и Активно/Пасивно, потребно е да се обезбеди конзистентност на податоците во релациона база на податоци - двата јазли на базата на податоци мора синхроно да се реплицираат помеѓу различни гео-дистрибуирани центри за податоци.

Наједноставниот пример за инсталација толерантна за грешки.

Кои се предностите од користењето на еден кластер:

• Висока достапност и перформанси.
• Поддршка за режими на работа: Активни / Активни, Активни / Пасивни.
• Способност за динамичко размерување - кога се користи виртуелизација на контејнери.
• Можност за централизирано управување и следење.
• Унифициран пристап за идентификување/автентикација/овластување на корисниците во проектите.
• Потранспарентна интеракција помеѓу различни проекти без интеракција со корисникот.
• Способност за повторна употреба на токенот JWT во различни проекти.
• Единствена точка на доверба.
• Побрзо лансирање на проекти со користење на микросервиси/виртуелизација на контејнер (нема потреба да се инсталираат и конфигурираат дополнителни компоненти).
• Можно е да се купи комерцијална поддршка од продавачот.

Што да се земе предвид при планирање на кластер

ДБМС

Keycloak користи систем за управување со DBMS за зачувување: области, клиенти, корисници итн.
Поддржан е широк опсег на DBMS: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak доаѓа со сопствена вградена релациона база на податоци. Се препорачува да се користи за неоптоварени средини - како што се развојни околини.

За да се работи во режими на кластери Активни/Активни и Активни/Пасивни, неопходно е да се обезбеди конзистентност на податоците во релациската база на податоци и двата јазли од кластерот на базата на податоци синхроно се реплицираат помеѓу центрите за податоци.

Дистрибуиран кеш (Infinspan)

За правилно функционирање на кластерот, потребна е дополнителна синхронизација на следните типови кешови со помош на JBoss Data Grid:

Сесии за автентикација - се користат за зачувување на податоци при автентикација на одреден корисник. Барањата од овој кеш обично ги вклучуваат само прелистувачот и серверот Keycloak, а не апликацијата.

Акциони токени - се користат за сценарија каде што корисникот треба асинхроно да потврди дејство (преку е-пошта). На пример, за време на протокот на заборавена лозинка, кешот Infinispan actionTokens се користи за следење на метаподатоците за поврзаните токени за акција што веќе се користени, па затоа не може повторно да се користи.

Кеширање и поништување на постојани податоци - се користи за кеширање на постојани податоци за да се избегнат непотребни прашања во базата на податоци. Кога некој сервер на Keycloak ги ажурира податоците, сите други сервери на Keycloak во сите центри за податоци треба да знаат за тоа.

Работа - Се користи само за испраќање невалидни пораки помеѓу јазлите на кластерот и центрите за податоци.

Кориснички сесии - се користат за складирање на податоци за кориснички сесии кои важат за времетраењето на сесијата на прелистувачот на корисникот. Кешот мора да обработува HTTP барања од крајниот корисник и апликацијата.

Заштита од брутална сила - се користи за следење на податоците за неуспешни најавувања.

Балансирање на товарот

Балансерот на оптоварување е единствената влезна точка на тастатурата и мора да поддржува лепливи сесии.

Сервери за апликации

Тие се користат за контрола на интеракцијата на компонентите едни со други и може да се виртуелизираат или контејнеризираат со користење на постоечки алатки за автоматизација и динамично скалирање на алатките за автоматизација на инфраструктурата. Најчестите сценарија за распоредување во OpenShift, Kubernates, Rancher.

Со ова се заокружува првиот дел - теоретскиот. Во следната серија написи, ќе бидат анализирани примери на интеграции со различни даватели на идентитети и примери на поставки.

Извор: www.habr.com