Подключение Keycloak к Spring Boot приложению

[gsaw]

Мне вот интересно. Это обычная практика вставлять аутентификацию в само spring приложение?

А то я решил в проекте использовать Apache модуль для аутентификации пользователя. Мне показалось так правильнее отделить бизнесприложение от наносного. И вроде как к примеру mod_auth_openidc сертифицирован, но почему то очень мало по нему находится примеров использования в интернете. Практически только документация на гитхабе и пара комментариев на в issues на том же гитхабе.

Так то оно все прекрасно работает, но что то меня грызут червяки сомнений.

[avkazakov]

Мне вот интересно. Это обычная практика вставлять аутентификацию в само spring приложение?

Здесь аутентификация на стороне Keycloak происходит

[gsaw]

Да это понятно. Не знаю тогда как назвать ту часть, что встраивается в приложение. На ум больше ничего не приходит. Проверка наличия токена, переадресация кейклоку, запрос токена итд. Все это имхо часть аутентификации.

[avkazakov]

Если большая система, то обязанность проверки и переадресации обычно возлагают на API Gateway. Но часто оставляют проверку на наличие токена и валидацию его подписи в самих сервисах, чтобы предотвратить, на всякий случай, несанкционированный доступ.

[ladutsko]

Поддержу Вас в вопросе выноса аутентификации из приложения. Конечно нужно рассматривать каждый случай отдельно и если в принципе только одно приложение, то почему бы и да.

Другое дело авторизация. Проверка разрешений бывает вшита в сервисы и по этому все равно придется получать эти разрешения для текущего пользователя. Это может не сильно отличаться от процесса аутентификации.

[shuron]

У меня такой случай. Gateway есть…
Вот думаю может там токены в едином месте и проверять. А сервисам за Gateway слать клеймы в headerах. Обычно нужен только ID пользователя…
Мне кажется преимуществом была бы единая точка проверки. Все сервисы из одной домены и в кругу одной команды и одном уровне доверия.
Или есть в этой практике прям очевидные минусы?

[avkazakov]

Такой подход тоже часто используют. Если у вас сервисы хорошо защищены от запросов извне, то можно убрать security совсем из сервисов, так мы уберем дополнительную обязанность с микросервисов. Но в этом случае у вас Gateway становится бутылочным горлышком.

А как вы планируете разделять API по ролям по url запроса на gateway или в header класть информацию о роли пользователя?
Или различные точки входа(возможно разные API Gateway) для разных ролей пользователя?

[shuron]

У нас пока онда роль и одна гейтвей. Разделять особо нечего. Бутылочное горлышко — это гейтвей по определению ;)

[maxkan]

Спасибо, очень полезная статья

[saakovv]

Добрый день,
Важно в сервисах авторизации не забывать об использовании SSL…

[Iamme]

Спасибо, полезно. Но почему для клиента использован spring-boot-starter-oauth2-client, а для сервера ресурсов spring-security-oauth2-resource-server? (есть spring-boot-starter-oauth2-resource-server; он новее, как я понимаю)

[avkazakov]

Добрый день!
spring-boot-starter-oauth2-resource-server это стартер, он в себе содержит также зависимость spring-security-oauth2-resource-server, вы можете в этом убедиться, посмотрев зависимости, которые он загружает

[Lastro]

Отличная статья!