Русский
Keycloak Хостинг
Предоставить централизованное управление идентификацией, единый вход, федерацию пользователей и управление доступом к приложениям.
- Один клик развернуть
- 50 ГБ Необходимое дисковое пространство
- 4 ГБ ОЗУ Необходимая память
- От 10 € Цена
Без сборов за установку
Официальные ссылки
Официальные ссылки и оригинальный сайт Keycloak
- Больше
Сайт Keycloak
Что вы получаете
на AvaHost
Развертывание в один клик, собственный домен, бесплатный HTTPS, автоматические обновления приложений и запланированные резервные копии включены в каждое облачное приложение. Вы можете запускать несколько приложений на одном сервере, и доступ к терминалу включен.
Контейнер PostgreSQL предоставляется с приложением и не управляется AvaHost.
Технологии
- Образ Docker
- quay.io/keycloak/keycloak:26.0
- Порт по умолчанию
- 8080
- База данных
- postgres
Как работает Keycloak
Keycloak находится между пользователями и приложениями, к которым им нужен доступ. Администраторы создают realms, регистрируют clients, определяют адреса перенаправления, настраивают roles и выбирают потоки аутентификации. Приложения затем используют OpenID Connect, OAuth 2.0 или SAML для делегирования входа вместо независимой реализации каждой функции логина.
Identity brokering может отправлять пользователей к внешнему провайдеру OpenID Connect или SAML, а user federation может подключать поддерживаемые сервисы каталогов, такие как LDAP или Active Directory. Консоль администрирования управляет пользователями, группами, сеансами, clients, scopes, role mappings и настройками realm из одного места.
Ключевые возможности Keycloak
Single sign-on позволяет одному аутентифицированному сеансу обслуживать несколько совместимых приложений. Детальные настройки client и role контролируют, какие identities могут получить доступ к каждому сервису. Themes настраивают страницы, видимые пользователям, а потоки аутентификации могут комбинировать пароли, одноразовые credentials, passkeys, внешних провайдеров и другие настроенные шаги.
Централизованная identity также создаёт сосредоточенную ответственность за безопасность. Redirect URIs, client secrets, federation connections, учётные записи администраторов, время жизни tokens и signing keys должны управляться тщательно. Ошибка конфигурации может повлиять на несколько приложений одновременно, поэтому изменения следует тестировать в отдельном realm перед широким использованием.
Keycloak vs Auth0
Keycloak
Keycloak — это self-hosted сервер управления идентификацией и доступом со стандартизированными протоколами, администрированием realm, user federation и identity brokering. Auth0 — это облачная платформа идентификации, предлагающая размещённый вход, SSO, социальные и беспарольные методы, MFA, machine-to-machine доступ и инфраструктуру, управляемую поставщиком.
Auth0
Auth0 может подойти командам, которые хотят, чтобы провайдер управлял платформой идентификации и предоставлял управляемые функции безопасности через коммерческий сервис. Keycloak более уместен, когда организация нуждается в прямом контроле над данными идентификации и конфигурацией, при условии, что она может управлять и аудировать критически важный для безопасности сервис.
Кто использует Keycloak
Команды разработки используют Keycloak как провайдер идентификации для внутренних инструментов, портальных приложений для клиентов, API и многоприложенческих сред. Крупные организации подключают каталоги или внешних провайдеров, а команды разработки используют отдельные realms для изоляции продуктов, окружений или групп клиентов.
Сервис не является заменой управлению доступом. Администраторам по-прежнему нужны политики для привилегированных учётных записей, регистрации clients, проверки roles, восстановления credentials, ограничения сеансов, сбоев federation и аварийного доступа.
Self-hosting Keycloak: требования и стоимость
Использование ресурсов растёт с количеством realms, clients, пользователей, активных сеансов, выдачи tokens, сложности аутентификации, трафика federation, логирования событий и административной активности. PostgreSQL хранит realms, пользователей, clients, roles, сеансы и конфигурацию. База данных включена, но не управляется, и её память находится вне экспортируемого минимума приложения.
AvaHost рекомендует Plan 4 за €20 для полного стека Keycloak после корректировки базы данных. Развёртывание в один клик, пользовательский домен идентификации, автоматический HTTPS, автоматические обновления приложения и запланированные резервные копии включены. Email приложения отключён, поэтому сообщения проверки, восстановления пароля и действий администратора не могут быть отправлены; realms должны быть спроектированы без зависимости от этих потоков.
F.A.Q
Keycloak начинается с €20 на Plan 4 с учётом PostgreSQL. План включает сервер идентификации, ёмкость базы данных, пользовательский домен, HTTPS, обновления и запланированные резервные копии. Количество realm, пользователей, активных сессий, трафик токенов, соединения федерации, логирование событий и сложность потока аутентификации определяют практический запас производительности.
PostgreSQL хранит области, пользователей, группы, клиентов, роли, сессии, учётные данные и конфигурацию сервера. AvaHost создаёт контейнер базы данных и подключает его к Keycloak, но сервис остаётся неуправляемым. Данные идентификации и конфигурация должны рассматриваться как система, чувствительная к безопасности, при планировании изменений, миграции, тестирования или восстановления.
Пользовательское имя хоста идентификации можно подключить с автоматическим HTTPS после настройки DNS. Адреса перенаправления клиента, URL-адреса издателя, параметры приложения и обратные вызовы внешнего поставщика идентификации должны использовать окончательное имя хоста. Протестируйте вход, выход, обновление токена, страницы учётной записи и каждого зарегистрированного клиента после изменения адреса.
Keycloak обычно использует SMTP для проверки электронной почты, ссылок восстановления пароля и сообщений действий, инициированных администратором. AvaHost отключает приложение электронной почты, поэтому эти рабочие процессы не могут отправлять почту из размещённого realm. Администраторам следует избегать требования проверки электронной почты, подготовить контролируемый процесс ручного восстановления и протестировать каждый поток аутентификации перед добавлением пользователей.