Skip to main content

Теория

https://www.youtube.com/watch?v=uq2I9z_ZB6Q

image.png

Прослойка, объединяющая технологии авторизации.

Функциональность:

  • Single-sign on, Single-sign out для браузерных приложений
  • Поддержка OpenID/OAuth 2.0/SAML
  • Identity Brokering - аутентификация с помощью внешних провайдеров, Social login
  • User federation - синхронизация с LDAP / Active directory / Kerberos
  • Консоль администратора

Блоки keycloak

Realm

Деление на блоки через realm. Каждый realm изолирован, пользователь принадлежит только одному realm. Содержит конфигурацию, набор приложений и пользователей. Есть административный и остальные realm.

Есть консоль управления реалм и консоль управления аккаунтом.

Клиенты (clients)

Клиенты - сущности, которые могут отправлять запрос в Keycloak на аутентификацию пользователя. 

Роли (realm roles)

Каждая роль может быть переключена в композитный режим (объединение других ролей).

Название Композитная Назначение
admin Да включает административные права - может управлять пользователями, клиентами, ролями и конфигурацией реалма
create-realm Нет позволяет пользователю создавать новые realms через Admin Console или REST API (только в master realm).
default-roles-master Да набор ролей, назначаемых по умолчанию всем новым пользователям master realm.
Включает offline_access, uma_authorization и другие (можно посмотреть внутри composite).
offline-access Нет дает возможность получать offline refresh tokens - живут дольше, не требуют активной сессии пользователя.
uma_authorization Нет позволяет использовать User-Managed Access (UMA) - механизм, при котором пользователь может делегировать доступ к своим ресурсам другим пользователям (используется при ресурсно-ориентированном доступе).

 

Консоль управления сервером

Доступ: ip_keycloak:8080/admin

Группы (организационная принадлежность) и роли (набор разрешений). Когда пользователь добавляется в группу, он наследует все роли. Единственная задача keycloak: Пользователь - Разрешение. Внутри роли сопоставляется разрешение. Группа упрощает управление пользователями.

Регистрация приложения. Чтобы приложение могло использовать ресурсы keycloak, оно должно быть зарегистрировано. Клиенты (Clients) - это сущности, которые могут отправлять запрос в Keycloak на аутентификацию пользователя. Раздел Clients. Клиенты делятся по идентификаторам. 


В меню Manage realms выбирается реалм, который мы будем редактировать. 

Имя реалма не должно содержать пробелов и т д.

Встроенные сервисы

Управление аккаунтом (пользователь) В списке клиентов отображается как clients-account.

Доступ: ip_keycloak:8080/realms/<realm_name>/account

Фронтенд управления аккаунтом (пользователь) В списке клиентов отображается как clients-account-console.

Взаимодействие с Keycloak через CLI или REST API. В списке клиентов отображается как clients-admin-cli. Типичный use-case: получение токена через kcadm.sh или curl для скриптов/CI/CD. Поддерживает client_credentials и password гранты. Пример: 

Отправим post запрос с параметрами username, password, grant_type=password, client-id=admin-cli по адресу 
http://.../realms/master/protocol/openid-connect/token

Ответом придет access_token который добавляется в Header запроса, 
поле Authorization значение Brearer <значение token>

теперь можно использовать API для работы.

Клиент для федерации идентичности (SSO между провайдерами). В списке клиентов отображается как Clients - broker. Пример: Keycloak как Identity Broker между Google, GitHub и другим Keycloak сервером.

Клиент для административной консоли Keycloak. В списке клиентов отображается как security-admin-console. Доступ: /admin/{realm}/console Используется: при входе в админ-панель, управлении реалмами, пользователями и клиентами.

Области видимости клиентов (client scopes)

Определяет данные и разрешения, получаемые клиентом в access token / ID token при аутентификации пользователя. Типы:

  • Default Этот scope всегда включается в токен по умолчанию, даже если клиент не запрашивает его явно.
  • Optional Scope будет применён только если клиент его запросит в параметре scope=... при авторизации.
  • (Unassigned) Scope не применяется клиенту вообще, пока его не назначат вручную или не укажут явно в токене.

Стандартные scopes: 

Название Тип Протокол Назначение
acr Default OpenID Connect добавляет в токен acr (Authentication Context Class Reference) - уровень аутентификации (например, MFA, пароль и т. д.).
address Optional OpenID Connect добавляет адрес пользователя (address claim) в токен (если заполнено в профиле).
basic Default OpenID Connect включает базовые claims - sub, name, preferred_username, given_name, family_name
e-mail Default OpenID Connect

добавляет email и email_verified claims в ID и Access токены
microprofile-jwt Optional OpenID Connect

обеспечивает совместимость с Eclipse MicroProfile JWT - популярным стандартом для Java microservices
offline_access Optional OpenID Connect

разрешает выдачу offline refresh token (живёт долго и используется без пользовательского взаимодействия).
role_list Default SAML

включает список ролей (roles) пользователя в SAML assertions
roles Default OpenID Connect

добавляет роли пользователя (realm roles и client roles) в access token (в realm_access.roles и resource_access)

Также есть phone, profile

Back to top