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

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

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

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

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

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

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

Упълномощаване - това е предоставянето на достъп до ресурс (например до електронна поща).

Identity Broker Keycloak

ключодържател е решение за управление на идентичност и достъп с отворен код, предназначено за използване в IS, където могат да се използват модели на архитектура на микросервизи.

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

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

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

Корпоративни доставчици на идентичност (локални)

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

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

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

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

Доставчици на идентичност - социален вход

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

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

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

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

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

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

Implicit Flow не поддържа маркери за опресняване на токени за достъп.

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

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

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

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

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

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

Опресняване на токена е токен, който позволява на клиентите да поискат нови токени за достъп след изтичане на живота им. Тези токени обикновено се издават за дълъг период от време.

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

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

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

Заглавие - по подразбиране заглавката съдържа само типа токен и използвания алгоритъм за криптиране.

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

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

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

{ "електронна поща": "[имейл защитен]"}

Ключовете в полезния товар могат да бъдат произволни. Има обаче няколко запазени:

• iss (Издател) - Идентифицира приложението, от което се изпраща токенът.
• sub (Тема) - определя темата на токена.
• aud (Аудитория) е масив от чувствителни към регистър низове или URI, който е списък на получателите на този токен. Когато приемащата страна получи JWT с даден ключ, тя трябва да провери за присъствието си в получателите - в противен случай игнорирайте токена.
• exp (Expiration Time) – Показва кога токенът изтича. Стандартът JWT изисква всички негови реализации да отхвърлят изтекли токени. Ключът exp трябва да бъде клеймо за време в unix формат.
• nbf (Not Before) е време в unix формат, което определя момента, в който токенът става валиден.
• iat (Издаден в) - Този ключ представлява времето, когато токенът е издаден и може да се използва за определяне на възрастта на JWT. Ключът iat трябва да бъде клеймо за време в unix формат.
• Jti (JWT ID) — низ, който дефинира уникалния идентификатор на този токен, чувствителен към главни и малки букви.

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

Base64-кодиран: заглавието и полезният товар се вземат, те се комбинират в низ чрез точка. След това този низ и секретният ключ се въвеждат в алгоритъма за криптиране, посочен в заглавката (ключ "alg"). Ключът може да бъде произволен низ. По-дългите струни ще бъдат най-предпочитани, тъй като ще отнеме повече време за набиране.

{"alg":"RSA1_5","payload":"A128CBC-HS256"}

Изграждане на Keycloak Failover Cluster Architecture

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

Увеличаването на риска от повреда на единичния SSO увеличава изискванията за архитектурата на решението и методите, използвани за излишни компоненти, и води до много стегнат SLA. В тази връзка, по-често по време на разработването или ранните етапи на внедряване на решения, проектите имат своя собствена инфраструктура, която не е устойчива на грешки. С напредването на развитието е необходимо да се определят възможности за развитие и мащабиране. Най-гъвкаво е да се изгради отказоустойчив клъстер чрез виртуализация на контейнер или хибриден подход.

За да работите в режимите Активен/Активен и Активен/Пасивен клъстер, е необходимо да се осигури съгласуваност на данните в релационна база данни - и двата възела на база данни трябва да бъдат синхронно репликирани между различни гео-разпределени центрове за данни.

Най-простият пример за устойчива на грешки инсталация.

Какви са предимствата от използването на един клъстер:

• Висока наличност и производителност.
• Поддръжка на режими на работа: Активен / Активен, Активен / Пасивен.
• Възможност за динамично мащабиране - при използване на виртуализация на контейнер.
• Възможност за централизирано управление и наблюдение.
• Унифициран подход за идентификация/автентификация/авторизация на потребители в проекти.
• По-прозрачно взаимодействие между различни проекти без участие на потребителите.
• Възможността за повторно използване на JWT токена в различни проекти.
• Единична точка на доверие.
• По-бързо стартиране на проекти, използващи микроуслуги/виртуализация на контейнери (няма нужда от повдигане и конфигуриране на допълнителни компоненти).
• Възможно е да закупите търговска поддръжка от доставчика.

Какво да търсите, когато планирате клъстер

СУБД

Keycloak използва система за управление на база данни, за да съхранява: сфери, клиенти, потребители и др.
Поддържа се широк набор от СУБД: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak идва със собствена вградена релационна база данни. Препоръчително е да се използва за незаредени среди - като среди за разработка.

За да работите в режими на активен/активен и активен/пасивен клъстер, се изисква съгласуваност на данните в релационна база данни и двата възела на клъстера на база данни се репликират синхронно между центровете за данни.

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

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

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

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

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

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

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

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

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

Устройството за балансиране на натоварването е единствената входна точка към keycloak и трябва да поддържа лепкави сесии.

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

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

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

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