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.
• Identity Brokering – автентикация чрез външни идентификационни доставчици OpenID Connect или SAML.
• Social Login – подкрепа за Google, GitHub, Facebook, Twitter за идентификация на потребителите.
• User Federation – синхронизиране на потребители от LDAP и Active Directory сървъри и други идентификационни доставчици.
• Kerberos bridge – използване на Kerberos сървър за автоматична автентикация на потребителите.
• Admin Console — за единно управление на настройките и параметрите на решението чрез Web.
• Консола за управление акаунт – за самостоятелно управление на профила на потребителите.
• Персонализиране на решенията въз основа на фирмен стил.
• Двуфакторна автентикация – поддръжка на TOTP/HOTP с Google Authenticator или FreeOTP.
• Процеси на вход – възможност за саморегистрация на потребители, възстановяване и нулиране на паролата и други.
• Управление на сесии – администраторите могат да управляват сесиите на потребителите от една точка.
• Token Mappers – свързване на атрибути на потребители, роли и други необходими атрибути в токените.
• Гъвкаво управление на политиките чрез realm, приложение и потребители.
• Поддръжка на CORS – клиентските адаптери имат вградена поддръжка за CORS.
• Интерфейси за услуги (SPI) – голямо количество SPI за конфигуриране на различни аспекти на работата на сървъра: потоци за автентикация, идентификационни доставчици, съпоставяне на протоколи и много други.
• Клиентски адаптери за JavaScript приложения, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
• Поддръжка за работа с различни приложения, които поддържат OpenID Connect Relying Party library или SAML 2.0 Service Provider Library.
• Възможност за разширяване с използване на приставки.

За 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 cluster за MariaDB 10.1.19.

Идентификационни доставчици – социално логване

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

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

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

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

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

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

Имплицитният поток не поддържа токени за актуализиране на токена за достъп (refresh tokens).

Поток на клиентски кредити — се използва, когато приложението получава достъп до 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 (Время истечения) — указва се, кога изтича срокът на валидност на маркера. Стандартът JWT изисква всички реализации да отхвърлят маркери с изтекъл срок. Ключът Exp трябва да е времева маркировка в Unix формат.
• nbf (Не преди) — това е времева маркировка в Unix формат, която определя момента, когато токенът ще бъде валиден.
• iat (Издадено в) — този ключ представлява времето, когато маркерът е издаден и може да се използва за определяне на възрастта на JWT. Ключът iat трябва да е времева маркировка в Unix формат.
• Jti (JWT ID) — низ, определящ уникален идентификатор на този токен с оглед на регистъра.

Важно е да се разбере, че полезната информация не се предава в зашифрован вид (въпреки че токените могат да бъдат вложени и тогава е възможно да се предават зашифровани данни). Следователно в нея не могат да се съхраняват никакви секретни данни. Както заглавието, така и полезната информация се кодира в base64.
Подпис — когато имаме заглавие и полезна информация, можем да изчислим подписа.

Вземат се кодирани в base64: заглавието и полезната информация, те се комбинират в низ чрез точка. След това този низ и тайният ключ влизат като вход на алгоритма за криптиране, указан в заглавието (ключ "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 кластер е необходимо да се осигури консистентност на данните в релационната база данни и двата възела на кластерните бази данни да се репликират синхронно между ЦОД.

Разпределен кеш (Infinispan)

За правилната работа на кластера е необходима допълнителна синхронизация на следните типове кеш с използване на JBoss Data Grid:

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

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

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

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

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

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

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

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

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

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

С това приключва първата част – теоретичната. В следващите цикли от статии ще разгледаме примери за интеграции с различни доставчици на идентификация и примери за настройки.

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