Skip to main content

Теория

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

can_do_it = F(user, data, action)

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

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

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.

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

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

Роли и группы

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


 Роли Группы
Назначение права доступа организация пользователей
Уровень низкий (atomic) высокий (aggregation)
Используются в коде Да Косвенно
Наследование Нет Да
Иерархия Нет Да

Т е группы служат скорее для удобства управления пользователями в 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

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

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

Back to top