Теория

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

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 при аутентификации пользователя.

Роли и группы

Роли - атомарное право или набор прав, который назначается пользователю. Группы - иерархическая структура. Отличия между ролями и группами:

Т е группы служат скорее для удобства управления пользователями в keycloak, фактическое разрешение действий происходит за счет ролей. 

Самое важное: keycloak просто отдает сопоставление пользователь - роль. Группа - дополнительное удобство.

Ограничения на стороне приложения.

Могут быть настроены на уровне realm и client. 

{
  "realm_access": {
    "roles": ["admin"]
  },
  "resource_access": {
    "my-client": {
      "roles": ["editor"]
    }
  }
}

Здесь admin - роль уровня realm, editor - роль уровня client. Роли используются для проверки доступа в коде. Но есть возможность перенести проверку разрешения выполнения endpoint на keycloak.

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

Доступ: 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 
  • Opaque. Непрозрачный токен (например, 8fa3b2e1-cb4e-4fd7-b517-84fc4c2f3a77), просто идентификатор. Для получения деталей ресурсный сервер обращеается к серверу авторизации. Плюсы: безопаснее (минимальные утечки данных через токен), легче отозвать токен централизованно. Минусы: нужен дополнительный сетевой вызов для валидации токена, больше нагрузка на сервер авторизации.
  • JWT самостоятельный токен, в себе несёт всю информацию (пользователь, права, срок жизни и т.д.). Токен подписан, ресурсный сервер проверяет токен без запроса к серверу авторизации. Плюсы: нет лишних сетевых вызовов на проверку и быстрее работает на стороне ресурсных серверов. Минусы: выданный токен нельзя "убить" мгновенно (если только через сложные механизмы типа revocation lists) и токен может содержать чувствительную информацию - важно правильно шифровать или минимизировать payload. Есть сайт jwt.io для просмотра данных из токена.
• Refresh Token - продление действия access token. Отправляется на сервер и сессия продлевается.
• ID Token - (только в OIDC) информация о пользователе

Grant types Технологии, посредством которых клиент получает токен.

Authorization code - получение кода и обмен его на токен доступа