У любой буйной кампаніі, і X5 Retail Group не выключэнне, па меры развіцця ўзрастае колькасць праектаў, дзе патрабуецца аўтарызацыя карыстальнікаў. З цягам часу патрабуецца бясшвоўны пераход карыстачоў з аднаго прыкладання ў іншы і тады ўзнікае неабходнасць выкарыстання адзінага сервера Single-Sing-On (SSO). Але што рабіць, калі такія ідэнтыфікацыйныя правайдэры як AD ці іншыя, не якія валодаюць дадатковымі атрыбутамі, ужо выкарыстоўваюцца ў розных праектах. На дапамогу прыйдзе клас сістэм пад назвай "ідэнтыфікацыйныя брокеры". Найбольш функцыянальнымі з'яўляюцца яго прадстаўнікі, такія як Keycloak, Gravitee Access management і інш. Часцей за ўсё сцэнары выкарыстання могуць быць розныя: машыннае ўзаемадзеянне, удзел карыстальнікаў і інш. Рашэнне павінна падтрымліваць гнуткі і які маштабуецца функцыянал, здольны аб'яднаць усе патрабаванні ў адным, і такія рашэннем у нашай кампаніі зараз з'яўляецца індыкацыйны брокер - Keycloak.
Keycloak - гэта прадукт з адкрытым зыходным кодам, прызначаны для ідэнтыфікацыі і кантролю доступу і які падтрымліваецца кампаніяй RedHat. Ён з'яўляецца асновай для прадуктаў кампаніі выкарыстоўвалых SSO - RH-SSO.
асноўныя паняцці
Перш чым пачаць разбірацца з рашэннямі і падыходамі, варта вызначыцца ў тэрмінах і паслядоўнасці працэсаў:
ідэнтыфікацыя - Гэта працэдура распазнання суб'екта па яго ідэнтыфікатару (прасцей кажучы, гэта вызначэнне імя, лагіна або нумара).
аўтэнтыфікацыя – гэта працэдура праверкі сапраўднасці (карыстальніка правяраюць з дапамогай пароля, ліст правяраюць па электронным подпісе і г.д.)
Аўтарызацыя - гэта прадастаўленне доступу да якога-небудзь рэсурсу (напрыклад, да электроннай пошты).
Ідэнтыфікацыйны брокер Keycloak
Плашч-ключ — гэтае рашэнне для кіравання ідэнтыфікацыяй і доступам з адчыненым зыходным кодам, прызначанае для выкарыстання ў ІС дзе могуць выкарыстоўвацца патэрны мікрасэрвіснай архітэктуры.
Keycloak прапануе такія функцыі, як адзіны ўваход (SSO), брокерская ідэнтыфікацыя і сацыяльны ўваход у сістэму, федэрацыя карыстальнікаў, кліенцкія адаптары, кансоль адміністратара і кансоль кіравання уліковымі запісамі.
Базавы функцыянал, які падтрымліваецца ў Keycloak:
- Single-Sign On and Single-Sign Out для браузерных прыкладанняў.
- Падтрымка OpenID/OAuth 2.0/SAML.
- Identity Brokering - аўтэнтыфікацыя з дапамогай знешніх OpenID Connect або SAML ідэнтыфікацыйных правайдэраў.
- Social Login - падтрымка Google, GitHub, Facebook, Twitter для ідэнтыфікацыі карыстальнікаў.
- User Federation - сінхранізацыя карыстальнікаў з LDAP і Active Directory сервераў і іншых ідэнтыфікацыйных правайдэраў.
- Kerberos bridge - выкарыстанне Kerberos сервера для аўтаматычнай аўтэнтыфікацыі карыстальнікаў.
- Admin Console - для адзінага кіравання наладамі і параметрамі рашэння праз Web.
- Account Management Console - для самастойнага кіравання профілем карыстальнікаў.
- Кастамізацыя рашэння на аснове фірмовага стылю кампаніі.
- 2FA Authentication - падтрымка TOTP/HOTP з дапамогай Google Authenticator або FreeOTP.
- Login Flows - магчымая самарэгістрацыя карыстальнікаў, аднаўленне і скід пароля і іншыя.
- Session Management - адміністратары могуць кіраваць з адзінай кропкі сесіямі карыстальнікаў.
- Token Mappers - прывязка атрыбутаў карыстальнікаў, роляў і іншых патрабаваных атрыбутаў у токены.
- Гнуткае кіраванне палітыкамі праз realm, application і карыстальнікаў.
- CORS Support - кліенцкія адаптары маюць убудаваную падтрымку CORS.
- Service Provider Interfaces (SPI) - вялікая колькасць SPI, якія дазваляюць наладжваць розныя аспекты працы сервера: струмені аўтэнтыфікацыі, ідэнтыфікацыйных правайдэраў, супастаўленне пратаколаў і шматлікае іншае.
- Кліенцкія адаптары для JavaScript applications, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Падтрымка працы з рознымі праграмамі, якія падтрымліваюць OpenID Connect Relying Party library або SAML 2.0 Service Provider Library.
- Магчымасць пашырэння з выкарыстаннем plugins.
Для працэсаў CI/CD, а гэтак жа аўтаматызацыі працэсаў кіравання ў Keycloak, можа выкарыстоўвацца REST API/JAVA API. Дакументацыя даступна ў электронным выглядзе:
REST API
JAVA API
Ідэнтыфікацыйныя правайдэры ўзроўню прадпрыемства (On-Premise)
Магчымасць аўтэнтыфікацыі карыстальнікаў праз User Federation сэрвісы.
Таксама можа быць выкарыстана скразная аўтэнтыфікацыя - калі карыстальнікі праходзяць аўтэнтыфікацыю на працоўных станцыях з Kerberos (LDAP або AD), то яны могуць быць аўтаматычна аўтэнтыфікаваны на Keycloak без неабходнасці зноў паказваць сваё імя карыстальніка і пароль.
Для аўтэнтыфікацыі і далейшай аўтарызацыі карыстальнікаў магчыма выкарыстанне рэляцыйнай СКБД, што найбольш дастасавальна для асяроддзяў распрацоўкі, бо не цягне працяглых налад і інтэграцый на ранніх стадыях праектаў. Па змаўчанні ў Keycloak выкарыстоўваецца ўбудаваная СКБД для захоўвання налад і дадзеных аб карыстачах.
Спіс падтрымліваемых СКБД шырокі і ўключае ў сябе: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle і іншыя. Найбольш пратэставанымі на дадзены момант з'яўляюцца Oracle 12C Release1 RAC і Galera 3.12 cluster для MariaDB 10.1.19.
Ідэнтыфікацыйныя правайдэры - social login
Магчыма выкарыстанне лагіна з сацыяльных сетак. Для актывацыі магчымасці аўтэнтыфікаваць карыстальнікаў выкарыстоўваецца кансоль адміністратара Keycloack. Змен у кодзе прыкладанняў не патрабуецца і дадзены функцыянал даступны "са скрынкі" і можа быць актываваны ў любой стадыі рэалізацыі праекта.
Для аўтэнтыфікацыі карыстальнікаў магчыма выкарыстанне OpenID/SAML Identity правайдэраў.
Тыпавыя сцэнары аўтарызацыі з выкарыстанне OAuth2 у Keycloak
Authorization Code Flow - Выкарыстоўваецца з сервернымі прыкладаннямі (server-side applications). Адзін з найболей распаўсюджаных тыпаў дазволу на аўтарызацыю, паколькі ён добра падыходзіць для серверных прыкладанняў, у якіх зыходны код прыкладання і дадзеныя кліента не даступныя староннім. Працэс у дадзеным выпадку будуецца на перанакіраванні (redirection). Прыкладанне павінна быць у стане ўзаемадзейнічаць з карыстацкім агентам (user-agent), такім як вэб-браўзэр - атрымліваць коды аўтарызацыі API перанакіроўваныя праз карыстацкі агент.
Implicit Flow - Выкарыстоўваецца мабільнымі або вэб-прыкладаннямі (прыкладанні, якія працуюць на прыладзе карыстальніка).
Няяўны тып дазволу на аўтарызацыю выкарыстоўваецца мабільнымі і вэб-прыкладаннямі, дзе канфідэнцыяльнасць кліента не можа быць гарантаваная. Няяўны тып дазволу таксама выкарыстоўвае перанакіраванне карыстацкага агента, пры гэтым токен доступу перадаецца карыстацкаму агенту для далейшага выкарыстання ў дадатку. Гэта робіць токен даступным карыстачу і іншым прыкладанням на прыладзе карыстальніка. Пры гэтым тыпе дазволу на аўтарызацыю не ажыццяўляецца аўтэнтыфікацыя сапраўднасці дадатку, а сам працэс належыць на URL перанакіравання (зарэгістраваны раней у сэрвісе).
Implicit Flow не падтрымлівае токены абнаўлення токена доступу (refresh tokens).
Client Credentials Grant Flow - Выкарыстоўваюцца пры доступе прыкладання да API. Гэты тып дазволу на аўтарызацыю звычайна выкарыстоўваецца для ўзаемадзеянняў "сервер-сервер", якія павінны выконвацца ў фонавым рэжыме без неадкладнага ўзаемадзеяння з карыстачом. Струмень прадастаўлення уліковых дадзеных кліента дазваляе вэб-службе (канфідэнцыйнаму кліенту) выкарыстоўваць уласныя ўліковыя дадзеныя замест увасаблення карыстальніка для праверкі сапраўднасці пры выкліку іншай вэб-службы. Для больш высокага ўзроўню бяспекі магчыма задзірлівай службе выкарыстоўваць сертыфікат (замест агульнага сакрэту) у якасці уліковых дадзеных.
Спецыфікацыя OAuth2 апісана ў
JWT токен і яго перавагі
JWT (JSON Web Token) - адкрыты стандарт (), які вызначае кампактны і аўтаномны спосаб для абароненай перадачы інфармацыі паміж бакамі ў выглядзе JSON-аб'екта.
Згодна са стандартам, токен складаецца з трох частак у base-64 фармаце, падзеленых кропкамі. Першая частка завецца загалоўкам (header), у якой утрымоўваецца тып токена і назоў хэш-алгарытму для атрымання лічбавага подпісу. Другая частка захоўвае асноўную інфармацыю (карыстальнік, атрыбуты і г.д.). Трэцяя частка - лічбавы подпіс.
. .
Ніколі не захоўвайце токен у вашай БД. Таму што сапраўдны токен эквівалентны паролю, захоўваць токен - гэта ўсё роўна, што захоўваць пароль у адкрытым выглядзе.
Access-токен – гэта токен, які дае доступ яго ўладальніку да абароненых рэсурсаў сервера. Звычайна ён мае кароткі тэрмін жыцця і можа несці ў сабе дадатковую інфармацыю, такую як IP-адрас боку, які запытвае дадзены токен.
Refresh-токен - Гэта токен, які дазваляе кліентам запытваць новыя access-токены па заканчэнні іх часу жыцця. Дадзеныя токены звычайна выдаюцца на працяглы тэрмін.
Асноўныя перавагі прымянення ў мікрасэрвіснай архітэктуры:
- Магчымасць доступу да розных прыкладанняў і сэрвісаў з дапамогай аднаразовай аўтэнтыфікацыі.
- Пры адсутнасці шэрагу патрабаваных атрыбутаў у профілі карыстальнікаў магчыма даабагачэнне дадзенымі, якія могуць быць дададзены ў карысную нагрузку, у тым ліку і аўтаматызавана і "на лета".
- Адсутнічае неабходнасць захоўвання інфармацыі аб актыўных сесіях, серверны дадатак павінен толькі праверыць подпіс.
- Больш за гнуткае кіраванне доступам за кошт дадатковых атрыбутаў у карыснай нагрузцы.
- Ужыванне подпісы токена для загалоўка і карыснай нагрузкі падвышае бяспеку рашэння ў цэлым.
JWT токен - склад
Загаловак - па змаўчанні, загаловак утрымоўвае толькі тып токена і алгарытм, выкарыстоўваны для шыфравання.
Тып токена захоўваецца ў ключы "typ". Ключ "typ" ігнаруецца ў JWT. Калі ключ "тып" прысутнічае, яго значэнне павінна быць JWT, каб паказаць, што гэты аб'ект з'яўляецца JSON Web Token.
Другі ключ "alg" вызначае алгарытм, які выкарыстоўваецца для шыфравання токена. Па змаўчанні ён павінен быць усталяваны ў HS256. Загаловак кадуецца ў base64.
{ "alg": "HS256", "typ": "JWT"}
Payload (змесціва) - у карыснай нагрузцы захоўваецца любая інфармацыя, якую трэба праверыць. Кожны ключ у карыснай нагрузцы вядомы як "заяву". Напрыклад, у дадатак можна ўвайсці толькі па запрашэнні (закрытае прома). Калі мы хочам запрасіць кагосьці паўдзельнічаць, мы дасылаем яму ліст з запрашэннем. Важна праверыць, што адрас электроннай пошты належыць чалавеку, які прымае запрашэнне, таму мы ўключым гэты адрас у карысную нагрузку, для гэтага захаваем яго ў ключы "e-mail"
{ "email": "[электронная пошта абаронена]}
Ключы ў payload могуць быць адвольнымі. Тым не менш, ёсць некалькі зарэзерваваных:
- iss (Issuer) - вызначае дадатак, з якога адпраўляецца токен.
- sub (Subject) - вызначае тэму токена.
- aud (Audience) - масіў адчувальных да рэгістра радкоў або URI, які з'яўляецца спісам атрымальнікаў дадзенага токена. Калі прымаючы бок атрымлівае JWT з дадзеным ключом, яна павінна праверыць наяўнасць сябе ў атрымальніках – інакш праігнараваць токен.
- exp (Expiration Time) - паказвае, калі заканчваецца тэрмін дзеяння маркера. Стандарт JWT патрабуе, каб ва ўсіх яго рэалізацыях маркеры са скончаным тэрмінам дзеяння адхіляліся. Exp ключ павінен быць пазнакай часу ў unix фармаце.
- nbf (Not Before) - гэта час у unix фармаце, якое вызначае момант, калі токен стане валідным.
- iat (Issued At) - гэты ключ уяўляе сабой час, калі маркер быў выдадзены і можа быць выкарыстаны для вызначэння ўзросту JWT. iat ключ павінен быць пазнакай часу ў unix фармаце.
- Jti (JWT ID) - радок, якая вызначае унікальны ідэнтыфікатар дадзенага токена з улікам рэгістра.
Важна разумець, што карысная нагрузка не перадаецца ў зашыфраваным выглядзе (хоць, токены могуць быць укладзенымі і тады магчыма перадаваць зашыфраваныя дадзеныя). Таму ў ёй нельга захоўваць любую сакрэтную інфармацыю. Як і загаловак, карысная нагрузка кадуецца ў base64.
Подпіс - Калі ў нас ёсць загаловак і payload, можна вылічыць подпіс.
Бяруцца закадаваныя ў base64: загаловак і payload, яны аб'ядноўваюцца ў радок праз кропку. Затым гэты радок і сакрэтны ключ паступае на ўваход алгарытму шыфравання, паказанага ў загалоўку (ключ "alg"). Ключом можа быць любы радок. Больш за доўгія радкі будуць найбольш пераважней, паколькі спатрэбіцца больш часу на падбор.
{"alg":"RSA1_5",“payload":"A128CBC-HS256"}
Пабудова архітэктуры адмоваўстойлівага кластара Keycloak
Пры выкарыстанні адзінага кластара для ўсіх праектаў узнікаюць падвышаныя патрабаванні да рашэння для SSO. Калі колькасць праектаў невяліка гэтыя патрабаванні не так адчувальныя для ўсіх праектаў, аднак з павелічэннем колькасці карыстачоў і інтэграцый павялічваюцца патрабаванні да даступнасці і прадукцыйнасці.
Падвышэнне рызык адмовы адзінага SSO павялічвае патрабаванні да архітэктуры рашэння і выкарыстоўваных метадаў рэзервавання кампанентаў і прыводзіць да вельмі цвёрдага SLA. У сувязі з гэтым часцей пры распрацоўцы або ранніх стадыях укаранення рашэнняў праекты маюць уласную не адмоваўстойлівасць інфраструктуру. Па меры развіцця трэба закласці магчымасці развіцця і маштабавання. Найбольш гнутка будаваць адмоваўстойлівасць кластар з ужываннем кантэйнернай віртуалізацыі або гібрыднага падыходу.
Для працы ў рэжыме Active/Active і Active/Passive кластара патрабуецца забяспечваць кансістэнтнасць дадзеных у рэляцыйнай базе дадзеных - абодва вузла базы дадзеных павінны сінхронна рэпліцыравацца паміж рознымі геаразмеркаванымі ЦАД.
Самы просты прыклад адмоваўстойлівай інсталяцыі.
Якія перавагі дае выкарыстанне адзінага кластара:
- Высокая даступнасць і прадукцыйнасць.
- Падтрымка рэжымаў працы: Active/Active, Active/Passive.
- Магчымасць дынамічнага маштабавання - пры выкарыстанні кантэйнернай віртуалізацыі.
- Магчымасць цэнтралізаванага кіравання і маніторынгу.
- Адзіны падыход для ідэнтыфікацыі/аўтэнтыфікацыі/аўтарызацыі карыстальнікаў у праектах.
- Больш празрыстае ўзаемадзеянне паміж рознымі праектамі без удзелу карыстальнікаў.
- Магчымасць перавыкарыстання JWT токена ў розных праектах.
- Адзіная кропка даверу.
- Больш хуткі запуск праектаў з выкарыстаннем мікрасэрвісаў/кантэйнернай віртуалізацыі (не патрабуецца ўзняцце і настройка дадатковых кампанентаў).
- Магчыма набыццё камерцыйнай падтрымкі ад вендара.
На што варта звярнуць увагу пры планаванні кластара
СКБД
Keycloak выкарыстоўвае сістэму кіравання СКБД для захавання: realms, clients, users і інш.
Падтрымліваецца вялікі спектр СКБД: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak пастаўляецца з уласнай убудаванай рэляцыйнай базай дадзеных. Рэкамендуецца выкарыстанне для ненагружаных асяроддзяў - такія як асяроддзя распрацоўкі.
Для працы ў рэжыме Active/Active і Active/Passive кластара патрабуецца забяспечваць кансістэнтнасць дадзеных у рэляцыйнай базе дадзеных і абодва вузла кластара баз дадзеных сінхронна рэпліцыруюцца паміж ЦАД.
Размеркаваны кэш (Infinspan)
Для карэктнай працы кластара патрабуецца дадатковая сінхранізацыя наступных тыпаў кэша з выкарыстаннем JBoss Data Grid:
Authentication sessions - які выкарыстоўваецца для захавання дадзеных пры аўтэнтыфікацыі канкрэтнага карыстальніка. Запыты з гэтага кэша звычайна ўключаюць толькі браўзэр і сервер Keycloak, а не дадатак.
Action tokens - выкарыстоўваюцца для сцэнарыяў, калі карыстачу неабходна пацвердзіць дзеянне асінхронна (па электроннай пошце). Напрыклад, падчас патоку forget password кэш actionTokens Infinispan выкарыстоўваецца для адсочвання метададзеных аб звязаных маркерах дзеянняў, якія ўжо выкарыстоўваліся, таму яго нельга выкарыстоўваць паўторна.
Caching and invalidation of persistent data - выкарыстоўваецца для кэшавання пастаянных дадзеных, каб пазбегнуць лішніх запытаў да базы дадзеных. Калі які-небудзь сервер Keycloak абнаўляе дадзеныя, усе астатнія серверы Keycloak ва ўсіх цэнтрах апрацоўкі дадзеных павінны ведаць аб гэтым.
Work - выкарыстоўваецца толькі для адпраўкі паведамленняў аб несапраўднасці паміж вузламі кластара і цэнтрамі апрацоўкі дадзеных.
User sessions — выкарыстоўваюцца для захавання даных аб сеансах карыстальніка, якія сапраўдныя на працягу сеанса браўзэра карыстальніка. Кэш павінен апрацоўваць HTTP-запыты ад канчатковага карыстальніка і дадатку.
Brute force protection – выкарыстоўваецца для адсочвання дадзеных аб няўдалых уваходах.
Балансіроўка нагрузкі
Балансавальнік нагрузкі з'яўляецца адзінай кропкай уваходу ў keycloak і павінен падтрымліваць sticky sessions.
Сервера прыкладанняў
Выкарыстоўваюцца для кантролю ўзаемадзеяння кампанентаў паміж сабой і могуць быць віртуалізаваны або кантэйнерызаваны з ужываннем наяўных сродкаў аўтаматызацыі і дынамічнага маштабавання сродкаў аўтаматызацыі інфраструктуры. Найбольш распаўсюджаныя сцэнары разгортвання ў OpenShift, Kubernates, Rancher.
На гэтым першая частка - тэарэтычная - скончана. У наступных цыклах артыкулаў будуць разабраны прыклады інтэграцый з рознымі ідэнтыфікацыйнымі правайдэрамі і прыклады налад.
Крыніца: habr.com