Спасибо за демонстрацию этого стартера - раньше только слышал про него (эдакий кубер на минималках). Заметил, что очень неудобно с текущей авторизацией, что надо каждый новый инструмент регистрировать в Keycloak. Может, тут стоило сделать отдельный мини-сервис (единую точку входа), куда вытащить авторизацию, а дальше чтобы все остальные запросы ходили между внутренними сервисами без авторизации? И несколько раз переслушивал, но так и не понял - зачем обычному пользователю доступ в Spring Boot Admin? Сюда же должен быть доступ только у админа безо всяких дополнительных авторизаций - просто добавляется requestMatcher на соответствующий эндпойнт с правами ADMIN, и всего делов. А вместо этого сознательно создана здоровенная дыра в безопасности, позволяя обычному пользователю не только увидеть закрытую информацию о приложении, но и давая ему инструменты, чтобы что-то поломать в сервисе...
А у Вас получилось ограничить доступ с помощью requestMatcher? Пытаюсь сейчас это реализовать но столкнулся с тем что все время получаю ошибку 403, хотя в keycloak вроде нужные роли и группы настроены. Буду благодарен за помощь!
Хороший контент. Много нового для себя узнал, хотя работаю со спрингом уже 3 года.
Как-то мимо меня прошел данный инструмент, если честно. Было полезно было послушать, спасибо.
О, нужная тема. Мало кто рассказывает про это
Респект коллега. Нужная тема.
Спасибо за видео! Респект)
Спасибо за видео!
Спасибо за демонстрацию этого стартера - раньше только слышал про него (эдакий кубер на минималках).
Заметил, что очень неудобно с текущей авторизацией, что надо каждый новый инструмент регистрировать в Keycloak.
Может, тут стоило сделать отдельный мини-сервис (единую точку входа), куда вытащить авторизацию, а дальше чтобы все остальные запросы ходили между внутренними сервисами без авторизации?
И несколько раз переслушивал, но так и не понял - зачем обычному пользователю доступ в Spring Boot Admin? Сюда же должен быть доступ только у админа безо всяких дополнительных авторизаций - просто добавляется requestMatcher на соответствующий эндпойнт с правами ADMIN, и всего делов. А вместо этого сознательно создана здоровенная дыра в безопасности, позволяя обычному пользователю не только увидеть закрытую информацию о приложении, но и давая ему инструменты, чтобы что-то поломать в сервисе...
А у Вас получилось ограничить доступ с помощью requestMatcher? Пытаюсь сейчас это реализовать но столкнулся с тем что все время получаю ошибку 403, хотя в keycloak вроде нужные роли и группы настроены. Буду благодарен за помощь!
Вообще вам часто приходиться работать с кейклоак, или много приложений используют собственную jwt аутентификацию как обычный спринг секьюрити?
По-всякому бывает, если приложение интегрируется в корпоративную инфраструктуру, то OAuth/OIDC (Keycloak, CAS), если просто JWT-аутентификация
Вообще мне кажется такие вещи должны быть где-то за VPNом внутри VPC, тогда и авторизация будет не нужна.
Даже в DMZ во внутрикорпоративных сетях во всех сервисах используется не только аутентификация и авторизация, но и SSL/TLS
"Ауторайздклаентсервайсреактивоауз2ауторайздклаентмэнэджер" это мощно конечно... спрасибо спринг))
Тем временем aspectj: HasThisTypePatternTriedToSneakInSomeGenericOrParameterizedTypePatternMatchingStuffAnywhereVisitor