Теория
Функциональность:
- Single-sign on, Single-sign out для браузерных приложений
- Поддержка OpenID/OAuth 2.0/SAML
- Identity Brokering - аутентификация с помощью внешних провайдеров, Social login
- User federation - синхронизация с LDAP / Active directory / Kerberos
- Консоль администратора
Для деления на блоки используются Realm. Каждый Realm изолирован от остальных. В нем хранится конфигурация, набор приложений и пользователи.
Master realm администрирование системы.
Есть консоль управления реалм и консоль управления аккаунтом.
Роли (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 при аутентификации пользователя. По-другому это способ контролировать, что именно получит клиент при запросе авторизации у пользователя. Типы assigned type:
- 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 |
| 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
Доступ:Настройка realm (realm settings)
OpenID Endpoint configuration - здесь можно увидеть все endpoint настроенные для данного realm.
Настройка процесса аутентификации. ip_keycloak:8080/realms/realm_name/accountРаздел Authentication используется для настройки и управления потоками аутентификации, обязательными действиями, и политиками входа.
Authentication flow (поток аутентификации) - это набор шагов, через которые проходит пользователь или клиент при входе, регистрации, сбросе пароля и т.д. Каждый поток состоит из действий (executions): например, проверка пароля, OTP, условные переходы, выбор IdP и др.
Потоки создаются и настраиваются.
Типы токенов
- Access Token - доступ к API
- Refresh Token - продление действия access token
- ID Token - (только в OIDC) информация о пользователе
User Federation
Используется для подключения к внешним источникам пользователей (LDAP, Active Directory или Kerberos). С помощью федерации:
- пользователи остаются в LDAP/AD/Kerberos;
- Keycloak может их аутентифицировать;
- можно синхронизировать или кэшировать данные (имя, email, роли и т.д.);
- поддерживается одноразовый вход (SSO), если внешняя система это позволяет.