SSO на микросервисна архитектура. Използваме Keycloak. Част №1

Във всяка голяма компания, и X5 Retail Group не е изключение, с развитието на проекта нараства и броят на проектите, в които е необходима авторизация на потребители. С времето се изисква безпроблемен преход на потребителите от едно приложение в друго и тогава се появява необходимостта от използване на единен сървър за Single-Sign-On (SSO). Но какво да правим, когато идентификационни доставчици като AD или други, които нямат допълнителни атрибути, вече се използват в различни проекти? На помощ идва класът системи, наречен „идентификационни брокери“. Най-функционалните от тях са представители като Keycloak, Gravitee Access management и др. Най-често сценарии за използване могат да бъдат различни: машинно взаимодействие, участие на потребители и др. Решението трябва да поддържа гъвкав и мащабируем функционал, способен да обедини всички изисквания на едно място, а такова решение в нашата компания в момента е идентификационният брокер – Keycloak.

Keycloak е продукт с отворен код, предназначен за идентификация и контрол на достъпа и се поддържа от компанията RedHat. Той е основата за продуктите на компанията, които използват SSO – RH-SSO.

Основни понятия

Преди да започнем да разбираме решенията и подходите, трябва да се определим в термините и в последователността на процесите:

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

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

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

Идентификационният брокер Keycloak

Keycloak — това е решение за управление на идентификация и достъп с отворен код, предназначено за използване в информационни системи, където могат да се използват модели на микросервисна архитектура.

Keycloak предлага такива функции като единен вход (SSO), брокерска идентификация и социално влизане, федерация на потребители, клиентски адаптери, администраторска конзола и конзола за управление на акаунти.

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

• Single-Sign On и Single-Sign Out за браузърни приложения.
• Поддръжка на OpenID/OAuth 2.0/SAML.
• Идентификационен брокер – удостоверяване чрез външни доставчици на идентичност OpenID Connect или SAML.
• Социално влизане – поддръжка на Google, GitHub, Facebook, Twitter за идентификация на потребителите.
• Обединяване на потребители – синхронизиране на потребители от LDAP и Active Directory сървъри и други доставчици на идентичност.
• Мост на Kerberos – използване на Kerberos сървър за автоматично удостоверяване на потребителите.
• Административна конзола — за централизирано управление на настройките и параметрите на решението чрез уеб.
• Конзола за управление на акаунти – за самостоятелно управление на профила на потребителите.
• Персонализиране на решението на базата на корпоративния стил.
• 2FA удостоверяване – поддръжка на TOTP/HOTP чрез Google Authenticator или FreeOTP.
• Процеси на влизане – възможна е саморегистрация на потребителите, възстановяване и нулиране на парола и други.
• Управление на сесии – администраторите могат да управляват сесиите на потребителите от единна точка.
• Token Mappers – свързване на атрибути на потребители, роли и други необходими атрибути в токени.
• Гъвкаво управление на политиките чрез realm, application и потребители.
• Поддръжка на CORS – клиентските адаптери имат вградена поддръжка за CORS.
• Интерфейси за предоставяне на услуги (SPI) – голям брой SPI, позволяващи конфигуриране на различни аспекти на работата на сървера: потоци на удостоверяване, доставчици на идентичност, сопоставяне на протоколи и много други.
• Клиентски адаптери за JavaScript приложения, 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 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

Доставчици на идентичност на ниво предприятие (On-Premise)

Възможност за удостоверяване на потребители чрез услуги за обединяване на потребители.

Също така може да се използва единично удостоверяване – ако потребителите се удостоверяват на работни станции с Kerberos (LDAP или AD), те могат да бъдат автоматично удостоверени в Keycloak, без да е необходимо отново да задават името си и паролата.

За удостоверяване и по-нататъшно авторизиране на потребителите може да се използва релационна СУБД, което е най-подходящо за разработващи среди, тъй като не изисква дълги настройки и интеграции в ранните етапи на проектите. По подразбиране в Keycloak се използва вградена СУБД за съхранение на настройки и данни за потребителите.

Списъкът на поддържаните СУБД е обширен и включва: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle и други. Най-тестирани към момента са Oracle 12C Release1 RAC и Galera 3.12 клъстери за MariaDB 10.1.19.

Идентификационни доставчици — социално влизане

Възможно е използването на вход от социални мрежи. За активиране на възможността за удостоверяване на потребители се използва консолата на администратора на Keycloak. Няма нужда от промени в кода на приложенията и тази функционалност е налична "от кутията" и може да бъде активирана на всяка фаза на реализиране на проекта.

За удостоверяване на потребителите може да се използват OpenID/SAML идентификационни доставчици.

Типични сценарии за авторизация с използване на OAuth2 в Keycloak

Поток на код за авторизация — използва се с приложения на сървъра (server-side applications). Един от най-разпространените типове разрешение за авторизация, тъй като е подходящ за сървърни приложения, при които изходният код на приложението и данните на клиента не са достъпни за трети лица. Процесът в този случай се изгражда на базата на пренасочване (redirection). Приложението трябва да може да взаимодейства с потребителския агент (user-agent), например уеб браузър – да получава кодове за авторизация на API, пренасочвани през потребителския агент.

Имплицитен поток — използва се от мобилни или уеб приложения (приложения, работещи на устройството на потребителя).

Неявният тип разрешение за удостоверяване се използва от мобилни и уеб приложения, при които конфиденциалността на клиента не може да бъде гарантирана. Неявният тип разрешение също така използва пренасочване на потребителския агент, при което токенът за достъп се предава на потребителския агент, за да бъде използван в приложението. Това прави токена достъпен за потребителя и за други приложения на устройството. При този тип разрешение за удостоверяване не се извършва автентикация на приложението, а самият процес разчита на URL пренасочването (регистрирано преди в услугата).

Неявният поток не поддържа токени за обновяване на токена за достъп.

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

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

JWT токен и неговите предимства

JWT (JSON Web Token) е отворен стандарт (https://tools.ietf.org/html/rfc7519), който определя компактен и автономен начин за сигурна предаване на информация между страните под формата на JSON обект.

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

..
Никога не съхранявайте токена в базата си данни. Тъй като валидният токен е еквивалентен на парола, съхраняването на токен е все едно да съхранявате парола в открит вид.
Access-токен — това е токен, който предоставя на притежателя си достъп до защитени ресурси на сървъра. Обикновено той има кратък срок на годност и може да съдържа допълнителна информация, като IP адреса на страната, която иска този токен.

Refresh токен — това е токен, който позволява на клиентите да искат нови access токени след изтичането на техния срок. Тези токени обикновено се издават за дълъг период.

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

• Възможност за достъп до различни приложения и услуги чрез еднократна автентикация.
• При липса на редица необходими атрибути в профила на потребителите е възможно обогатяване на данните, което може да бъде добавено в полезната нагрузка, в това число и автоматизирано и "на лето".
• Не е необходимо съхраняване на информация за активни сесии, сървърното приложение трябва само да провери подписа.
• По-гъвкаво управление на достъпа благодарение на допълнителни атрибути в полезната нагрузка.
• Използването на подпис за токена за заглавието и полезната нагрузка увеличава сигурността на решението като цяло.

JWT токен — състав

Заглавието — по подразбиране заглавието съдържа само типа на токена и алгоритъма, използван за шифроване.

Типът токен се съхранява в ключа "typ". Ключът "typ" се игнорира в JWT. Ако ключът "typ" присъства, неговата стойност трябва да бъде JWT, за да посочи, че този обект е JSON Web Token.

Вторият ключ "alg" определя алгоритъма, използван за шифроване на токена. По подразбиране той трябва да бъде настроен на HS256. Заглавието е кодирано в base64.

{ "alg": "HS256", "typ": "JWT"}
Payload (съдържание) — в полезната нагрузка се съхранява всяка информация, която трябва да бъде проверена. Всеки ключ в полезната нагрузка е известен като "заявление". Например, в приложението може да се влезе само по покана (затворено промо). Когато желаем да поканим някого да участва, ние изпращаме имейл с поканата. Важно е да се провери, че електронната поща принадлежи на човека, който приема поканата, затова ще включим този адрес в полезната нагрузка, като го запазим в ключа "e-mail".

{ "email": "example@x5.ru" }

Ключовете в 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:

Сесии за удостоверяване — използват се за запазване на данни при удостоверяване на конкретен потребител. Запитванията от този кеш обикновено включват само браузъра и сървъра Keycloak, а не приложението.

Токени за действия — използват се за сценарии, при които на потребителя е необходимо да потвърди действие асинхронно (чрез имейл). Например, по време на потока за забравена парола кешът actionTokens Infinispan се използва за проследяване на метаданни за свързаните маркери на действия, които вече са били използвани, така че не могат да бъдат използвани повторно.

Кеширане и невалидиране на постоянни данни – използва се за кеширане на постоянни данни, за да се избегнат ненужни запитвания към базата данни. Когато някой сървър Keycloak актуализира данни, всички останали сървъри Keycloak в различни центрове за обработка на данни трябва да научат за това.

Работа — използва се само за изпращане на съобщения за невалидиране между възлите на клъстера и центровете за обработка на данни.

Потребителски сесии — използват се за запазване на данни за потребителските сесии, които са валидни в рамките на сесията на браузъра на потребителя. Кешът трябва да обработва HTTP запитвания от крайния потребител и приложението.

Защита от груба сила — използва се за проследяване на данни за неуспешни входове.

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

Балансировчикът на натоварването е единна точка за достъп до Keycloak и трябва да поддържа sticky сесии.

Сървъри на приложения

Използват се за контрол на взаимодействието между компонентите и могат да бъдат виртуализирани или контейнеризирани с помощта на налични средства за автоматизация и динамично мащабиране на инфраструктурната автоматизация. Най-честите сценарии за разгърнате в OpenShift, Kubernetes, Rancher.

С тази статия завършваме първата част — теоретичната. В следващите цикли от статии ще бъдат разгледани примери за интеграции с различни доставчици на удостоверяване и примери за настройки.

Източник: habr.com