У будь-якій великій компанії, і 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 – прив'язка атрибутів користувачів, ролей та інших необхідних атрибутів у токени.
- Гнучке управління політиками через реальність, застосування та користувачів.
- 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
API Java
Ідентифікаційні провайдери рівня підприємства (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.
Ідентифікаційні провайдери.
Можливе використання логіну із соціальних мереж. Для активації можливості автентифікації користувачів використовується консоль адміністратора 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". Ключ "тип" ігнорується в JWT. Якщо ключ «type» є присутнім, його значення має бути 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