Теория

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

can_do_it = F(user, data, action)

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

Приложение перенаправляет пользователя в 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: Пользователь - Разрешение. Внутри роли сопоставляется разрешение. Группа упрощает управление пользователями.

Протоколы и технологии

LDAP

Lightweight Directory Access Protocol - протокол доступа к каталогу пользователей, используемый для хранения и получения информации о пользователях, группах, ролях и другой организационной информации.
Не занимается безопасной аутентификацией сам по себе - только хранит данные.

LDAP = база пользователей и их свойств

Kerberos

Протокол аутентификации, основанный на криптографии и "билетах".
Позволяет пользователю один раз войти в систему (SSO) и получать доступ к другим сервисам без повторного ввода пароля.
Часто используется в доменных Windows-сетях. Основан на централизованном сервере (KDC - Key Distribution Center).
Kerberos = безопасный вход в систему + SSO

Сервер KDC:

Центральный сервер в протоколе Kerberos, отвечает за аутентификацию пользователей и выдачу билетов (tickets) для доступа к другим сервисам. KDC состоит из двух основных компонентов:

Authentication Server (AS) Проверяет логин и пароль пользователя и выдает TGT - ticket-granting ticket (билет доступа к другим билетам).

Ticket Granting Server (TGS) Получает TGT от пользователя и выдает сервисные билеты (service tickets) - они используются для доступа к конкретным приложениям, например, файловому серверу или веб-приложению.

OAuth 2.0 и OpenID Connect (OIDC)

Открытые протоколы безопасной аутентификации и авторизации пользователей в приложениях и API. Роли:

Клиент: приложение, запрашивающее доступ.

Ресурсный сервер: API с защищенными данными.

Пользователь: владелец данных.

Провайдер: сервер, выдающий токены и подтверждающий личность.

OAuth:

Протокол аутентификации. Не занимается аутентификацией пользователя напрямую.

Главная цель: разрешить приложению доступ к ресурсам пользователя (например, к его файлам, фото) без передачи пароля.

Работает через выдачу токенов доступа (Access Token).

Пример: приложение запрашивает у пользователя разрешение читать его документы в Google Docs.

OpenID Connect (OIDC)

Надстройка над OAuth 2.0, которая добавляет авторизацию пользователя.

OpenID Connect расширяет OAuth, чтобы приложение могло не только получить доступ к ресурсам, но и узнать, кто такой пользователь.

Добавляет понятие ID Token - это отдельный токен (в формате JWT), который содержит информацию о пользователе (имя, email и т.д.).

Типы токенов:

Access Token - доступ к API

Refresh Token - продление действия access token

ID Token - (только в OIDC) информация о пользователе