Комментарии 13
Мне вот интересно. Это обычная практика вставлять аутентификацию в само spring приложение?
А то я решил в проекте использовать Apache модуль для аутентификации пользователя. Мне показалось так правильнее отделить бизнесприложение от наносного. И вроде как к примеру mod_auth_openidc сертифицирован, но почему то очень мало по нему находится примеров использования в интернете. Практически только документация на гитхабе и пара комментариев на в issues на том же гитхабе.
Так то оно все прекрасно работает, но что то меня грызут червяки сомнений.
А то я решил в проекте использовать Apache модуль для аутентификации пользователя. Мне показалось так правильнее отделить бизнесприложение от наносного. И вроде как к примеру mod_auth_openidc сертифицирован, но почему то очень мало по нему находится примеров использования в интернете. Практически только документация на гитхабе и пара комментариев на в issues на том же гитхабе.
Так то оно все прекрасно работает, но что то меня грызут червяки сомнений.
0
Мне вот интересно. Это обычная практика вставлять аутентификацию в само spring приложение?Здесь аутентификация на стороне Keycloak происходит
0
Да это понятно. Не знаю тогда как назвать ту часть, что встраивается в приложение. На ум больше ничего не приходит. Проверка наличия токена, переадресация кейклоку, запрос токена итд. Все это имхо часть аутентификации.
0
Поддержу Вас в вопросе выноса аутентификации из приложения. Конечно нужно рассматривать каждый случай отдельно и если в принципе только одно приложение, то почему бы и да.
Другое дело авторизация. Проверка разрешений бывает вшита в сервисы и по этому все равно придется получать эти разрешения для текущего пользователя. Это может не сильно отличаться от процесса аутентификации.
Другое дело авторизация. Проверка разрешений бывает вшита в сервисы и по этому все равно придется получать эти разрешения для текущего пользователя. Это может не сильно отличаться от процесса аутентификации.
+1
У меня такой случай. Gateway есть…
Вот думаю может там токены в едином месте и проверять. А сервисам за Gateway слать клеймы в headerах. Обычно нужен только ID пользователя…
Мне кажется преимуществом была бы единая точка проверки. Все сервисы из одной домены и в кругу одной команды и одном уровне доверия.
Или есть в этой практике прям очевидные минусы?
0
Такой подход тоже часто используют. Если у вас сервисы хорошо защищены от запросов извне, то можно убрать security совсем из сервисов, так мы уберем дополнительную обязанность с микросервисов. Но в этом случае у вас Gateway становится бутылочным горлышком.
А как вы планируете разделять API по ролям по url запроса на gateway или в header класть информацию о роли пользователя?
Или различные точки входа(возможно разные API Gateway) для разных ролей пользователя?
А как вы планируете разделять API по ролям по url запроса на gateway или в header класть информацию о роли пользователя?
Или различные точки входа(возможно разные API Gateway) для разных ролей пользователя?
0
Спасибо, очень полезная статья
0
Добрый день,
Важно в сервисах авторизации не забывать об использовании SSL…
Важно в сервисах авторизации не забывать об использовании SSL…
+1
Спасибо, полезно. Но почему для клиента использован spring-boot-starter-oauth2-client, а для сервера ресурсов spring-security-oauth2-resource-server? (есть spring-boot-starter-oauth2-resource-server; он новее, как я понимаю)
0
Отличная статья!
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Подключение Keycloak к Spring Boot приложению