Теория

По логике система управления доступом должна разрешить/запретить пользователю выполнить действие с данными. Т е

can_do_it = F(user, data, action)

Причем система может быть как размещена снаружи и возвращать да или нет, так быть встроенной в систему и непосредственно блокировать действия.

Приложение перенаправляет пользователя в Keycloak. Тот запрашивает логин и пароль, возвращает обратно код. Приложение обменивает код на токен и начинает с ним работать. С этого момента пользователь считается авторизованным — можно проверять его права, роли и доступы.

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

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

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

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.

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

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

Роли (realm roles)

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

Название	Композитная	Только в master realm	Назначение
admin	Да	Да	Административные права: управление пользователями, клиентами, ролями и конфигурацией реалма
create-realm	Нет	Да	Создание новых realms через Admin Console или REST API.
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: Пользователь - Разрешение. Внутри роли сопоставляется разрешение. Группа упрощает управление пользователями.