Может ли wicked.io интегрироваться с keycloak таким образом, чтобы keycloak предоставлял идентификаторы и секреты клиентов и, конечно же, аутентификацию?

wicked.haufe.io сопровождающий здесь.

Сочетание wicked/Kong с KeyCloak может быть не очень хорошей идеей. Wicked решает множество проблем, для решения которых предназначен KeyCloak, и совпадение довольно велико, например. объединение удостоверений (SAML, OAuth2) с рабочим процессом OAuth2 и все такое.

Однако KeyCloak и wicked/Kong следуют разным принципам; KeyCloak выпускает токены, которые проверяются через библиотеку KeyCloak внутри ваших сервисов. Это более или менее заменяет шлюз API — он реализован внутри ваших сервисов на основе библиотеки KeyCloak.

wicked/Kong, поскольку контраст построен по-другому, где большим отличием является API-портал, который wicked предоставляет поверх Kong, и наличие выделенного API-шлюза (Kong). Wicked предоставляет вам свои собственные учетные данные клиента, а также хочет выполнить всю аутентификацию и авторизацию. В обмен на это вы получаете API-портал самообслуживания; если вам это не нужно, вам, вероятно, не понадобится злой.

То, что вы делаете, могу, — это федерация потока OAuth2 KeyCloak в wicked, заставляя KeyCloak выступать либо в качестве поставщика удостоверений SAML, либо OAuth2. Затем вы должны зарегистрировать свой сервер авторизации KeyCloak в качестве поставщика удостоверений с помощью wicked (используя одного поставщика услуг (SAML) или клиента (OAuth2)). «Но» здесь заключается в том, что вам все равно нужно будет предоставить точку входа для ваших сервисов, которые нет проходят через библиотеку KeyCloak.

wicked/Kong всегда работает следующим образом: устраняет необходимость реализации аутентификации/авторизации внутри ваших сервисов; вместо этого вам нужно проверить заголовки X-Authenticated-UserId и X-Authenticated-Scope. В wicked это обычно будет содержать что-то вроде sub=<some id>, также в зависимости от того, какой тип провайдера(ов) идентификации вы настроили для использования wicked. Но такой подход обычно заменяет KeyCloak. Положительным моментом является то, что у вас может быть одна единственная точка входа в ваши службы (=Kong), и у вас есть довольно легкий способ защиты произвольных служб — не только служб, написанных на языках, которые поддерживает KeyCloak! - за шлюзом API, предоставляя доступ к самообслуживанию (с настраиваемыми планами, документацией и т. д.) через портал API.

Все эти вещи, очевидно, несколько сложны; wicked чрезвычайно гибок в своем использовании, но на самом деле он не предназначен для объединения с KeyCloak (что аналогично. Все сводится к действительному пониманию варианта использования и поиску архитектуры решения, которая наилучшим образом решает ваш вариант использования.

Если ваши варианты использования связаны с порталом API и документацией по API (так и должно быть), может быть хорошей возможностью пойти на зло/Kong. Если это не так, вы можете быть счастливее, придерживаясь KeyCloak (которую вы можете рассматривать как безголовую систему управления API с децентрализованным шлюзом, который вам нужен).

Отказ от ответственности: Мои знания о KeyCloak несколько устарели; возможно, есть обновления, которые также идут в направлении API Portal, но об этом я не знаю.