ССО на микросервисној архитектури. Користимо Кеицлоак. Део 1

У било којој великој компанији, а Кс5 Ретаил Гроуп није изузетак, како се развија, повећава се број пројеката који захтевају ауторизацију корисника. Временом је неопходан несметан прелазак корисника из једне апликације у другу, а онда постоји потреба за коришћењем једног сервера са једним позивом (ССО). Али шта је са када се добављачи идентитета као што су АД или други који немају додатне атрибуте већ користе у разним пројектима. У помоћ ће прискочити класа система под називом „посредници за идентификацију”. Најфункционалнији су његови представници, као што су Кеицлоак, Гравитее Аццесс манагемент, итд. Најчешће случајеви употребе могу бити различити: интеракција машине, учешће корисника итд. Решење мора да подржава флексибилну и скалабилну функционалност која може да комбинује све захтеве у једном, а таква решења наша компанија сада има брокера за индикацију - Кеицлоак.

Кеицлоак је производ отвореног кода за идентитет и контролу приступа који одржава РедХат. То је основа за производе компаније који користе ССО - РХ-ССО.

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

Пре него што почнете да се бавите решењима и приступима, требало би да одлучите о терминима и редоследу процеса:

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

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

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

Идентити Брокер Кеицлоак

Кеицлоак је решење за управљање идентитетом и приступом отвореног кода дизајнирано за употребу у ИС где се могу користити обрасци микросервисне архитектуре.

Кеицлоак нуди функције као што су јединствена пријава (ССО), посредовани идентитет и пријављивање на друштвене мреже, корисничка федерација, клијентски адаптери, администраторска конзола и конзола за управљање налогом.

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

• Једнострука пријава и једнократна пријава за апликације претраживача.
• Подршка за ОпенИД/ОАутх 2.0/САМЛ.
• Идентити Брокеринг – аутентификација помоћу екстерних ОпенИД Цоннецт или САМЛ добављача идентитета.
• Друштвено пријављивање – подршка за Гоогле, ГитХуб, Фацебоок, Твиттер за идентификацију корисника.
• Федерација корисника – синхронизација корисника са ЛДАП и Ацтиве Дирецтори сервера и других провајдера идентитета.
• Керберос мост - коришћење Керберос сервера за аутоматску аутентификацију корисника.
• Админ Цонсоле – за обједињено управљање подешавањима и опцијама решења путем веба.
• Конзола за управљање налогом - за самостално управљање корисничким профилом.
• Прилагођавање решења засновано на корпоративном идентитету компаније.
• 2ФА аутентикација – ТОТП/ХОТП подршка користећи Гоогле Аутхентицатор или ФрееОТП.
• Токови пријављивања – могућа је саморегистрација корисника, враћање и ресетовање лозинке и друго.
• Управљање сесијама – администратори могу управљати сесијама корисника из једне тачке.
• Мапери токена – везивање корисничких атрибута, улога и других потребних атрибута за токене.
• Флексибилно управљање политикама у областима, апликацијама и корисницима.
• ЦОРС подршка - Клијентски адаптери имају уграђену ЦОРС подршку.
• Интерфејси добављача услуга (СПИ) – Велики број СПИ-ова који вам омогућавају да прилагодите различите аспекте сервера: токове аутентификације, добављаче идентитета, мапирање протокола и још много тога.
• Клијентски адаптери за ЈаваСцрипт апликације, ВилдФли, ЈБосс ЕАП, Фусе, Томцат, Јетти, Спринг.
• Подршка за рад са различитим апликацијама које подржавају библиотеку ОпенИД Цоннецт Релиинг Парти или САМЛ 2.0 библиотеку добављача услуга.
• Прошириво помоћу додатака.

За ЦИ / ЦД процесе, као и аутоматизацију процеса управљања у Кеицлоак-у, може се користити РЕСТ АПИ / ЈАВА АПИ. Документација је доступна у електронском облику:

РЕСТ АПИ https://www.keycloak.org/docs-api/8.0/rest-api/index.html
ЈАВА АПИ https://www.keycloak.org/docs-api/8.0/javadocs/index.html

Добављачи идентитета предузећа (локални)

Могућност аутентификације корисника преко услуга Усер Федератион.

Пролазна аутентификација се такође може користити – ако су корисници аутентификовани на радним станицама са Керберос-ом (ЛДАП или АД), онда се могу аутоматски аутентификовати на Кеицлоак-у без потребе да поново уносе своје корисничко име и лозинку.

За аутентификацију и даљу ауторизацију корисника могуће је користити релациони ДБМС, који је најприменљивији за развојна окружења, јер не подразумева дуготрајна подешавања и интеграције у раним фазама пројеката. Подразумевано, Кеицлоак користи уграђени ДБМС за складиштење подешавања и корисничких података.

Листа подржаних ДБМС-ова је обимна и укључује: МС СКЛ, Орацле, ПостгреСКЛ, МариаДБ, Орацле и друге. Најтестиранији у овом тренутку су Орацле 12Ц Релеасе1 РАЦ и Галера 3.12 кластер за МариаДБ 10.1.19.

Провајдери идентитета – пријава на друштвеним мрежама

Могуће је користити пријаву са друштвених мрежа. Да бисте омогућили могућност аутентификације корисника, користите Кеицлоацк администраторску конзолу. Нису потребне никакве промене у коду апликације и ова функционалност је доступна без употребе и може се активирати у било којој фази пројекта.

Могуће је користити ОпенИД/САМЛ добављаче идентитета за аутентификацију корисника.

Типични сценарији ауторизације који користе ОАутх2 у Кеицлоак-у

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

имплицитни ток - користе мобилне или веб апликације (апликације које се покрећу на корисниковом уређају).

Тип дозволе имплицитне ауторизације користе мобилне и веб апликације где се не може гарантовати поверљивост клијента. Имплицитни тип дозволе такође користи преусмеравање корисничког агента, при чему се токен за приступ прослеђује корисничком агенту за даљу употребу у апликацији. Ово чини токен доступним кориснику и другим апликацијама на корисниковом уређају. Ова врста дозволе за ауторизацију не потврђује идентитет апликације, а сам процес се ослања на УРЛ за преусмеравање (претходно регистрован у сервису).

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

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

ОАутх2 спецификација је описана у
РФЦ-6749
РФЦ-8252
РФЦ-6819

ЈВТ токен и његове предности

ЈВТ (ЈСОН веб токен) је отворени стандард (https://tools.ietf.org/html/rfc7519), који дефинише компактан и самосталан начин за сигуран пренос информација између страна у облику ЈСОН објекта.

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

. .
Никада не чувајте токен у својој ДБ. Пошто је важећи токен еквивалент лозинке, чување токена је као чување лозинке у чистом тексту.
Приступни токен је токен који свом власнику даје приступ сигурним серверским ресурсима. Обично има кратак животни век и може да садржи додатне информације као што је ИП адреса стране која захтева токен.

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

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

• Могућност приступа различитим апликацијама и услугама путем једнократне аутентификације.
• У недостатку одређеног броја потребних атрибута у корисничком профилу, могуће је обогатити подацима који се могу додати корисном учитавању, укључујући аутоматизоване и „он-тхе-фли“.
• Нема потребе за чувањем информација о активним сесијама, серверска апликација само треба да провери потпис.
• Флексибилнија контрола приступа кроз додатне атрибуте у терету.
• Коришћење потписа токена за заглавље и корисни терет повећава безбедност решења у целини.

ЈВТ токен - састав

Наслов — подразумевано, заглавље садржи само тип токена и алгоритам који се користи за шифровање.

Тип токена се чува у кључу "тип". Кључ 'типе' се игнорише у ЈВТ-у. Ако је кључ „тип“ присутан, његова вредност мора бити ЈВТ да би се показало да је овај објекат ЈСОН веб токен.

Други кључ "алг" специфицира алгоритам који се користи за шифровање токена. Подразумевано би требало да буде подешено на ХС256. Заглавље је кодирано у басе64.

{ "алг": "ХС256", "типе": "ЈВТ"}
носивост (садржај) - носивост чува све информације које треба проверити. Сваки кључ у корисном учитавању је познат као "тврдња". На пример, у апликацију можете да уђете само по позиву (затворена промоција). Када желимо да позовемо некога да учествује, шаљемо му позивно писмо. Важно је да проверите да ли адреса е-поште припада особи која прихвата позивницу, тако да ћемо ову адресу укључити у корисни садржај, за то је чувамо у кључу „е-пошта“

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

Кључеви у носивости могу бити произвољни. Међутим, постоји неколико резервисаних:

• исс (Иссуер) - одређује апликацију из које се шаље токен.
• суб (Субјецт) - дефинише субјект лексеме.
• ауд (Аудиенце) – низ стрингова осетљивих на велика и мала слова или УРИ-ја који је листа прималаца овог токена. Када страна која прима ЈВТ са датим кључем, мора сама да провери у примаоцима - иначе игнорише токен.
• екп (Време истека) – Означава када токен истиче. ЈВТ стандард захтева да све имплементације одбију истекле токене. Кључ Екп мора бити временска ознака у уник формату.
• нбф (Не пре) је време у уникс формату које одређује тренутак када токен постаје важећи.
• иат (Иссуед Ат) – Овај кључ представља време када је токен издат и може се користити за одређивање старости ЈВТ-а. Иат кључ мора бити временска ознака у уник формату.
• Јти (ЈВТ ИД) је стринг који дефинише јединствени идентификатор који разликује велика и мала слова за овај токен.

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

Басе64 кодирано: заглавље и корисни терет се узимају, комбинују се у стринг кроз тачку. Затим се овај стринг и тајни кључ уносе у алгоритам шифровања наведен у заглављу (кључ „алг“). Кључ може бити било који низ. Дуже жице ће бити најпожељније јер ће требати дуже да се покупе.

{"алг":"РСА1_5","паилоад":"А128ЦБЦ-ХС256"}

Изградња Кеицлоак Фаиловер кластера архитектуре

Када се користи један кластер за све пројекте, постоје повећани захтеви за ССО решење. Када је број пројеката мали, ови захтеви нису толико уочљиви за све пројекте, међутим, са повећањем броја корисника и интеграција повећавају се и захтеви за доступношћу и перформансама.

Повећање ризика од квара једног ССО-а повећава захтеве за архитектуром решења и методама које се користе за редундантне компоненте и доводи до веома тесног СЛА. С тим у вези, чешће током развоја или раних фаза имплементације решења, пројекти имају сопствену инфраструктуру која није отпорна на грешке. Како развој напредује, потребно је утврдити могућности за развој и скалирање. Најфлексибилније је изградити кластер за превазилажење грешке користећи виртуелизацију контејнера или хибридни приступ.

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

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

Које су предности коришћења једног кластера:

• Висока доступност и перформансе.
• Подршка за режиме рада: Ацтиве / Ацтиве, Ацтиве / Пассиве.
• Могућност динамичког скалирања - када се користи виртуелизација контејнера.
• Могућност централизованог управљања и надзора.
• Јединствен приступ за идентификацију/аутентификацију/ауторизацију корисника у пројектима.
• Транспарентнија интеракција између различитих пројеката без учешћа корисника.
• Могућност поновног коришћења ЈВТ токена у различитим пројектима.
• Јединствена тачка поверења.
• Брже покретање пројеката помоћу микросервиса/виртуелизације контејнера (нема потребе за инсталирањем и конфигурисањем додатних компоненти).
• Могуће је купити комерцијалну подршку од продавца.

На шта треба обратити пажњу приликом планирања кластера

ДБМС

Кеицлоак користи систем управљања базом података за складиштење: домена, клијената, корисника итд.
Подржан је широк спектар ДБМС-ова: МС СКЛ, Орацле, МиСКЛ, ПостгреСКЛ. Кеицлоак долази са сопственом уграђеном релационом базом података. Препоручује се за употребу у окружењима са лаким оптерећењем, као што су развојна окружења.

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

Дистрибуирани кеш (Инфинспан)

Да би кластер исправно функционисао, потребна је додатна синхронизација следећих типова кеша користећи ЈБосс Дата Грид:

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

Токени акције се користе за сценарије у којима корисник треба да потврди акцију асинхроно (путем е-поште). На пример, током тока заборављања лозинке, ацтионТокенс Инфиниспан кеш се користи за праћење метаподатака о повезаним токенима акције који су већ коришћени, тако да се не може поново користити.

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

Посао – Користи се само за слање неважећих порука између чворова кластера и центара података.

Корисничке сесије – користе се за чување података о сесији корисника који су важећи за време трајања сесије претраживача корисника. Кеш мора да обрађује ХТТП захтеве крајњег корисника и апликације.

Заштита грубом силом – користи се за праћење података о неуспелим пријавама.

Балансирање оптерећења

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

Апплицатион Серверс

Користе се за контролу међусобне интеракције компоненти и могу бити виртуелизоване или контејнеризоване коришћењем постојећих алата за аутоматизацију и динамичког скалирања алата за аутоматизацију инфраструктуре. Најчешћи сценарији примене у ОпенСхифт, Кубернатес, Ранцхер.

Овим је завршен први део – теоријски. У следећој серији чланака биће анализирани примери интеграција са различитим провајдерима идентитета и примери подешавања.

Извор: ввв.хабр.цом