Кандайдыр бир чоң компанияда жана X5 Retail Group да четте калбайт, анткени өнүгүүнүн жүрүшү менен колдонуучунун уруксатын талап кылган долбоорлордун саны көбөйөт. Убакыттын өтүшү менен колдонуучулардын бир тиркемеден экинчисине үзгүлтүксүз өтүшү талап кылынат жана андан кийин бирдиктүү Single-Sing-On (SSO) серверин колдонуу зарылчылыгы пайда болот. Бирок, AD же кошумча атрибуттары жок башкалар сыяктуу идентификациялык камсыздоочулар ар кандай долбоорлордо мурунтан эле колдонулганда эмне кылуу керек. "Идентификациялык брокерлер" деп аталган системалардын классы жардамга келет. Эң функционалдуулары анын өкүлдөрү болуп саналат, мисалы, Keycloak, Gravitee Access башкаруу ж.б. Көп учурда колдонуу сценарийлери ар кандай болушу мүмкүн: машинанын өз ара аракеттенүүсү, колдонуучунун катышуусу ж. жана мындай чечим Биздин компания азыр көрсөткүч брокери бар - Keycloak.
Keycloak бул RedHat тарабынан колдоого алынган ачык булактуу идентификация жана кирүү мүмкүнчүлүгүн көзөмөлдөө продуктусу. Бул SSO - RH-SSO колдонуу менен компаниянын өнүмдөрү үчүн негиз болуп саналат.
негизги түшүнүктөр
Чечимдерди жана ыкмаларды түшүнө баштоодон мурун процесстердин шарттарын жана ырааттуулугун аныкташыңыз керек:
аныктоо субъектти анын идентификатору боюнча таануу процедурасы (башкача айтканда, бул ысымдын, логиндин же номердин аныктамасы).
тастыктоо – бул аутентификация процедурасы (колдонуучу пароль аркылуу текшерилет, кат электрондук кол тамга аркылуу текшерилет ж.б.)
укук берүү - бул ресурска кирүү мүмкүнчүлүгүн берүү (мисалы, электрондук почтага).
Keycloak Identity Broker
клавиатура микросервис архитектура үлгүлөрү колдонулушу мүмкүн болгон ИСде колдонуу үчүн иштелип чыккан ачык булактуу идентификация жана мүмкүндүктү башкаруу чечими.
Keycloak бир жолу кирүү (SSO), ортомчу идентификация жана социалдык логин, колдонуучу федерациясы, кардар адаптерлери, администратор консолу жана эсеп башкаруу консолу сыяктуу функцияларды сунуштайт.
Keycloak'та колдоого алынган негизги функциялар:
- Серепчи колдонмолору үчүн бир жолу кирүү жана бир жолу чыгуу.
- OpenID/OAuth 2.0/SAML колдоо.
- Identity Brokering – тышкы OpenID Connect же SAML идентификациялык камсыздоочуларын колдонуу менен аутентификация.
- Коомдук Кирүү - Google, GitHub, Facebook, Twitter колдонуучуларды идентификациялоо үчүн колдоо.
- Колдонуучу федерациясы – LDAP жана Active Directory серверлеринен жана башка идентификациялык камсыздоочулардан колдонуучуларды синхрондоштуруу.
- Kerberos көпүрөсү – колдонуучунун автоматтык түрдө аутентификациясы үчүн Kerberos серверин колдонуу.
- Admin Console - Интернет аркылуу орнотууларды жана чечим параметрлерин бирдиктүү башкаруу үчүн.
- Каттоо эсебин башкаруу консолу – көз карандысыз колдонуучунун профилин башкаруу үчүн.
- Компаниянын корпоративдик инсандыгынын негизинде чечимди ыңгайлаштыруу.
- 2FA аутентификация – Google Authenticator же FreeOTP аркылуу TOTP/HOTP колдоосу.
- Кирүү агымдары – колдонуучунун өзүн-өзү каттоосу, сырсөздү калыбына келтирүү жана баштапкы абалга келтирүү жана башкалар мүмкүн.
- Сеансты башкаруу – администраторлор колдонуучу сессияларын бир жерден башкара алышат.
- Token Mappers – колдонуучунун атрибуттарын, ролдорун жана башка талап кылынган атрибуттарды токендерге бириктирүү.
- Аймак, колдонмо жана колдонуучулар аркылуу ийкемдүү саясатты башкаруу.
- CORS Колдоо - Кардар адаптеринде орнотулган CORS колдоосу бар.
- Кызмат Провайдеринин Интерфейстери (SPI) – сервердин ар кандай аспектилерин конфигурациялоого мүмкүндүк берген көп сандагы SPI: аутентификация агымдары, идентификациялык камсыздоочулар, протоколдун картасы жана башкалар.
- JavaScript тиркемелери үчүн кардар адаптерлери, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- OpenID Connect Relying Party китепканасын же SAML 2.0 Кызмат Провайдеринин китепканасын колдогон ар кандай тиркемелер менен иштөө үчүн колдоо.
- Плагиндерди колдонуу менен кеңейтүүгө болот.
CI/CD процесстери үчүн, ошондой эле Keycloak башкаруу процесстерин автоматташтыруу үчүн REST API/JAVA API колдонсо болот. Документтер электрондук түрдө жеткиликтүү:
REST API
JAVA API
Ишкананын идентификациялык камсыздоочулары (Жеринде)
Колдонуучунун аутентификациясын Колдонуучу Федерациясынын кызматтары аркылуу жүргүзүү мүмкүнчүлүгү.
Өткөрүлгөн аутентификацияны да колдонсо болот - эгерде колдонуучулар Kerberos (LDAP же AD) менен иш станцияларында аутентификациядан өтүшсө, анда алар колдонуучу атын жана сырсөзүн кайра бербестен, Keycloak'ка автоматтык түрдө аутентификацияланышы мүмкүн.
Колдонуучулардын аутентификациясы жана андан аркы авторизациясы үчүн реляциялык DBMS колдонсо болот, ал иштеп чыгуу чөйрөлөрү үчүн эң ылайыктуу, анткени ал долбоорлордун алгачкы этаптарында узак орнотууларды жана интеграцияларды талап кылбайт. Демейки боюнча, Keycloak орнотууларды жана колдонуучунун маалыматтарын сактоо үчүн камтылган DBMS колдонот.
Колдоого алынган DBMS тизмеси кеңири жана төмөнкүлөрдү камтыйт: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle жана башкалар. Учурда эң көп сыналган Oracle 12C Release1 RAC жана MariaDB 3.12 үчүн Galera 10.1.19 кластери.
Идентификациялык камсыздоочулар - социалдык логин
Социалдык тармактардан логинди колдонсо болот. Колдонуучулардын аныктыгын текшерүү мүмкүнчүлүгүн иштетүү үчүн Keycloack администратор консолун колдонуңуз. Колдонмонун кодуна эч кандай өзгөртүүлөр талап кылынбайт жана бул функция кутудан тышкары жеткиликтүү жана долбоордун каалаган баскычында активдештирүү мүмкүн.
Колдонуучулардын аныктыгын текшерүү үчүн OpenID/SAML Identity провайдерлерин колдонсо болот.
Keycloak ичинде OAuth2 колдонуучу типтүү авторизация сценарийлери
Авторизация кодунун агымы - сервердик тиркемелер менен колдонулат. Авторизациялык уруксаттын эң кеңири таралган түрлөрүнүн бири, анткени ал колдонмонун баштапкы коду жана кардар маалыматтары бөтөн адамдар үчүн жеткиликтүү болбогон сервердик тиркемелер үчүн ылайыктуу. Бул учурда процесс кайра багыттоого негизделген. Колдонмо колдонуучу агенти (колдонуучу-агент) менен иштеше алышы керек, мисалы, веб-браузер - колдонуучу агенти аркылуу кайра багытталган API авторизация коддорун алуу үчүн.
Имплициттүү агым - мобилдик же веб-тиркемелер тарабынан колдонулат (колдонуучунун түзмөгүндө иштеген тиркемелер).
Кыйырсыз авторизациянын уруксат түрү мобилдик жана веб тиркемелери тарабынан колдонулат, анда кардардын купуялыгы кепилдикке алынбайт. Жашыруун уруксат түрү, ошондой эле колдонуучу агентинин багыттоосун колдонот, мында кирүү белгиси колдонуучу агентине кийинчерээк колдонуу үчүн өткөрүлүп берилет. Бул белгини колдонуучуга жана колдонуучунун түзмөгүндөгү башка колдонмолорго жеткиликтүү кылат. Авторизациялык уруксаттын бул түрү колдонмонун аныктыгын ырастабайт жана процесстин өзү багыттоо URL дарегине (мурда кызматта катталган) таянат.
Implicit Flow мүмкүндүк алуу токендерин жаңылоо белгилерин колдобойт.
Кардардын эсептик дайындары Грант агымы — колдонмо API'ге киргенде колдонулат. Авторизациялык уруксаттын бул түрү, адатта, колдонуучунун дароо аракеттешүүсүз фондо пайда болушу керек болгон серверден серверге өз ара аракеттенүү үчүн колдонулат. Кардардын эсептик дайындарын берүү агымы веб-кызматка (жашыруун кардар) башка веб-кызматка чалганда аныктыгын текшерүү үчүн колдонуучуну имитациялоонун ордуна өзүнүн эсептик дайындарын колдонууга мүмкүндүк берет. Коопсуздуктун жогорку деңгээли үчүн чалуучу кызмат тастыктаманы (жалпы сырдын ордуна) эсептик маалымат катары колдонсо болот.
OAuth2 спецификациясы сүрөттөлгөн
JWT токен жана анын артыкчылыктары
JWT (JSON Web Token) ачык стандарт болуп саналат () бул JSON объектиси катары тараптардын ортосунда маалыматты коопсуз өткөрүүнүн компакттуу жана өз алдынча жолун аныктайт.
Стандартка ылайык, токен чекиттер менен бөлүнгөн база-64 форматындагы үч бөлүктөн турат. Биринчи бөлүк токендин түрүн жана санариптик кол тамганы алуу үчүн хэш-алгоритмдин аталышын камтыган баш деп аталат. Экинчи бөлүктө негизги маалымат (колдонуучу, атрибуттар ж.б.) сакталат. Үчүнчү бөлүк - санариптик кол коюу.
. .
Токенди эч качан МБда сактабаңыз. Жарактуу токен сырсөзгө эквиваленттүү болгондуктан, токенди сактоо сырсөздү ачык текстте сактоо сыяктуу.
Жеткиликтүү белги анын ээсине корголгон сервердик ресурстарга кирүү мүмкүнчүлүгүн берген белги болуп саналат. Ал, адатта, кыска мөөнөткө ээ жана токенди сураган тараптын IP дареги сыяктуу кошумча маалыматты камтышы мүмкүн.
Токенди жаңыртуу кардарларга алардын иштөө мөөнөтү аяктагандан кийин жаңы жетүү токендерин суроого мүмкүндүк берген белги болуп саналат. Бул Токендер, адатта, узак мөөнөткө берилет.
Микросервис архитектурасын колдонуунун негизги артыкчылыктары:
- Бир жолку аутентификация аркылуу ар кандай тиркемелерге жана кызматтарга кирүү мүмкүнчүлүгү.
- Колдонуучунун профилинде бир катар талап кылынган атрибуттар жок болгон учурда, пайдалуу жүктөмгө кошула турган маалыматтар менен байытууга болот, анын ичинде автоматташтырылган жана ыкчам.
- Активдүү сеанстар жөнүндө маалыматты сактоонун кереги жок; сервердик тиркеме кол тамганы текшерүү үчүн гана керек.
- Пайдалуу жүктөгү кошумча атрибуттар аркылуу кирүү мүмкүнчүлүгүн башкаруу.
- Баш жана пайдалуу жүк үчүн белги кол коюуну колдонуу жалпы чечимдин коопсуздугун жогорулатат.
JWT токен - курамы
баш — демейки боюнча, баш маалымат токендин түрүн жана шифрлөө үчүн колдонулган алгоритмди гана камтыйт.
Токен түрү "тип" баскычында сакталат. JWTде "тип" баскычы этибарга алынбайт. "Тип" ачкычы бар болсо, бул объект JSON Web Token экенин көрсөтүү үчүн анын мааниси JWT болушу керек.
Экинчи ачкыч "alg" токенди шифрлөө үчүн колдонулган алгоритмди аныктайт. Демейки боюнча ал HS256га коюлушу керек. Баш аты base64 менен коддолгон.
{ "alg": "HS256", "typ": "JWT"}
пайдалуу жүк (мазмун) — пайдалуу жүк текшерүүнү талап кылган бардык маалыматты сактайт. Пайдалуу жүктөгү ар бир ачкыч "билдирме" деп аталат. Мисалы, сиз тиркемеге чакыруу менен гана кире аласыз (жабык акция). Биз кимдир-бирөөнү катышууга чакыргыбыз келгенде, биз ага чакыруу электрондук катын жөнөтөбүз. Электрондук почта дареги чакырууну кабыл алган адамга таандык экенин текшерүү маанилүү, андыктан бул даректи "электрондук почта" ачкычында сактоо менен пайдалуу жүккө кошобуз.
{ "электрондук почта": "[электрондук почта корголгон]" }
Пайдалуу жүктөгү ачкычтар каалагандай болушу мүмкүн. Бирок, сакталган бир нече бар:
- iss (Эмитент) - токен жөнөтүлгөн тиркемени аныктайт.
- sub (Subject) - токендин предметин аныктайт.
- aud (Аудитория) – бул энбелги алуучулардын тизмеси болгон регистрге сезимтал саптар же URI массивдери. Кабыл алуучу тарап берилген ачкыч менен JWT алганда, ал алуучуларда өзүн текшериши керек - антпесе токенге көңүл бурбаңыз.
- exp (Expiration Time) - Токендин мөөнөтү качан бүтөөрүн көрсөтөт. JWT стандарты бардык ишке ашыруу мөөнөтү өтүп кеткен токендерди четке кагышын талап кылат. Exp ачкычы unix форматындагы убакыт белгиси болушу керек.
- nbf (Мурда эмес) - бул токен жарактуу болгон учурду аныктаган unix форматындагы убакыт.
- iat (Issued At) - Бул ачкыч токен чыгарылган убакытты билдирет жана JWT жашын аныктоо үчүн колдонулушу мүмкүн. iat ачкычы unix форматындагы убакыт белгиси болушу керек.
- Jti (JWT ID) бул энбелги үчүн уникалдуу регистрге сезгич идентификаторду аныктаган сап.
Пайдалуу жүк шифрленген түрдө берилбей турганын түшүнүү маанилүү (токендерди уя салып, андан кийин шифрленген маалыматтарды өткөрүп берүүгө болот). Ошондуктан, анда эч кандай жашыруун маалыматты сактай албайсыз. Баш аты сыяктуу эле, пайдалуу жүк base64 коддолгон.
кол - Бизде баш жана пайдалуу жүк болгондон кийин, колду эсептей алабыз.
Base64 коддолгон: баш жана пайдалуу жүк алынат, алар чекит аркылуу сапка бириктирилет. Андан кийин бул сап жана жашыруун ачкыч аталышта көрсөтүлгөн шифрлөө алгоритмине киргизилет («alg» ачкычы). Ачкыч каалаган сап болушу мүмкүн. Узунураак жиптерге артыкчылык берилет, анткени аны алуу үчүн көбүрөөк убакыт талап кылынат.
{"alg":"RSA1_5","пайдалуу жүк":"A128CBC-HS256"}
Keycloak Failover Cluster архитектурасын куруу
Бардык долбоорлор үчүн бирдиктүү кластерди колдонууда SSO чечими үчүн талаптар жогорулайт. Долбоорлордун саны аз болгондо, бул талаптар бардык долбоорлор үчүн анчалык деле маанилүү эмес, бирок колдонуучулардын жана интеграциялардын саны көбөйгөн сайын, жеткиликтүүлүккө жана натыйжалуулукка талаптар көбөйөт.
Бир SSOнун иштебей калуу тобокелдигинин жогорулашы чечимдин архитектурасына жана компоненттердин ашыкча болушу үчүн колдонулган ыкмаларга талаптарды жогорулатат жана өтө катуу SLAга алып келет. Ушуга байланыштуу, көбүнчө иштеп чыгууда же чечимдерди ишке ашыруунун алгачкы этаптарында долбоорлордо өздөрүнүн катачылыкка чыдамдуу инфраструктурасы бар. Өнүгүү алдыга жылган сайын өнүгүү жана масштабдуу мүмкүнчүлүктөрдү түзүү зарыл. Иштебей калуу кластерин куруунун эң ийкемдүү жолу - бул контейнердик виртуалдаштырууну же гибриддик ыкманы колдонуу.
Активдүү/Активдүү жана Активдүү/Пассивдүү кластердик режимдерде иштөө үчүн реляциялык маалымат базасында маалыматтардын ырааттуулугун камсыз кылуу зарыл – эки маалымат базасы түйүндөрү ар кандай гео-бөлүштүрүлгөн маалымат борборлорунун ортосунда синхрондуу түрдө репликацияланышы керек.
Каталарга чыдамдуу орнотуунун эң жөнөкөй мисалы.
Бир кластерди колдонуунун кандай артыкчылыктары бар:
- Жогорку жеткиликтүүлүк жана аткаруу.
- Иштөө режимдерин колдоо: Активдүү/Активдүү, Активдүү/Пассивдүү.
- Динамикалык масштабдоо мүмкүнчүлүгү - контейнердик виртуалдаштырууну колдонууда.
- Борборлоштурулган башкаруу жана мониторинг жүргүзүү мүмкүнчүлүгү.
- Долбоорлордогу колдонуучуларды идентификациялоо/аныктыгын текшерүү/уруксат берүү үчүн бирдиктүү ыкма.
- Колдонуучунун катышуусуз ар кандай долбоорлордун ортосундагы ачык-айкын өз ара аракеттенүү.
- JWT энбелгисин ар кандай долбоорлордо кайра колдонуу мүмкүнчүлүгү.
- Ишенимдин бирдиктүү чекити.
- Микросервистерди/контейнерди виртуалдаштырууну колдонуу менен долбоорлорду тезирээк ишке киргизүү (кошумча компоненттерди орнотуу жана конфигурациялоонун кереги жок).
- Сатуучудан коммерциялык колдоону сатып алууга болот.
Кластерди пландаштырууда эмнени эске алуу керек
DBMS
Keycloak сактоо үчүн DBMS башкаруу системасын колдонот: аймактар, кардарлар, колдонуучулар, ж.б.
DBMSтин кеңири спектри колдоого алынат: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak өзүнүн орнотулган реляциялык маалымат базасы менен келет. Иштеп чыгуу чөйрөлөрү сыяктуу жеңил чөйрөдө колдонуу сунушталат.
Активдүү/Активдүү жана Активдүү/Пассивдүү кластер режимдеринде иштөө үчүн реляциялык маалымат базасында маалыматтардын ырааттуулугун камсыз кылуу зарыл жана маалымат базасы кластеринин эки түйүнү тең маалымат борборлорунун ортосунда синхрондуу түрдө репликацияланат.
Бөлүштүрүлгөн кэш (Infinspan)
Кластердин туура иштеши үчүн, JBoss Data Grid аркылуу төмөнкү кэш түрлөрүн кошумча синхрондоштуруу талап кылынат:
Аутентификация сессиялары - белгилүү бир колдонуучуну аутентификациялоодо маалыматтарды сактоо үчүн колдонулат. Бул кэштен сурамдар, адатта, колдонмону эмес, браузерди жана Keycloak серверин гана камтыйт.
Action tokens - колдонуучу иш-аракетти асинхрондуу түрдө ырасташы керек болгон сценарийлер үчүн колдонулат (электрондук почта аркылуу). Мисалы, паролду унутуу агымы учурунда Infinispan actionTokens кэши мурунтан эле колдонулган тиешелүү аракет белгилери жөнүндө метаберилиштерге көз салуу үчүн колдонулат, ошондуктан аны кайра колдонууга болбойт.
Туруктуу маалыматтарды кэштөө жана жараксыз кылуу – маалымат базасына керексиз суроону болтурбоо үчүн туруктуу маалыматтарды кэштөө үчүн колдонулат. Кайсы бир Keycloak сервери маалыматтарды жаңыртканда, бардык маалымат борборлорундагы бардык башка Keycloak серверлери бул тууралуу билиши керек.
Жумуш - кластердик түйүндөр менен маалымат борборлорунун ортосунда жараксыздык билдирүүлөрүн жөнөтүү үчүн гана колдонулат.
Колдонуучунун сеанстары - колдонуучунун сеанстарынын узактыгы үчүн жарактуу болгон колдонуучунун сеансынын маалыматтарын сактоо үчүн колдонулат. Кэш акыркы колдонуучудан жана колдонмодон келген HTTP сурамдарын аткарышы керек.
Оор күч менен коргоо - ишке ашпай калган кирүү жөнүндө маалыматтарды көзөмөлдөө үчүн колдонулат.
Жүктүн тең салмактуулугу
Жүктөлгөн баланстагыч клавиатураны жабуу үчүн бирдиктүү кирүү чекити болуп саналат жана жабышчаак сеанстарды колдоого алышы керек.
Колдонмо серверлери
Алар компоненттердин бири-бири менен өз ара аракеттенүүсүн көзөмөлдөө үчүн колдонулат жана учурдагы автоматташтыруу куралдарын жана инфраструктураны автоматташтыруу куралдарынын динамикалык масштабын колдонуу менен виртуалдаштырылган же контейнерлештирилиши мүмкүн. Эң кеңири таралган жайылтуу сценарийлери OpenShift, Kubernates, Rancher болуп саналат.
Бул биринчи бөлүгүн аяктайт - теориялык. Кийинки макалалар сериясында ар кандай идентификациялык камсыздоочулар менен интеграциянын мисалдары жана орнотуулардын мисалдары талкууланат.
Source: www.habr.com