Pull to refresh

Comments 6

Отличная статья! Понятный и практичный разбор реализации стартер-компонента с Keycloak и Spring Boot. Кэширование токенов и обработка ошибок впечатляют. Спасибо за примеры и тесты — очень полезно!

У Spring Boot есть starter для работы с OAuth2 spring-boot-starter-oauth2-resource-server. Так как Keycloak реализует стандарты OAuth2 и OpenID Connect, этот стартер работает и с keycloak (как и с любой другой реализацией сервера авторизации OAuth2), то чем ваш стартер лучше стандартного?

Здраствуйте,

Из того, ссылку на что Вы прислали

Spring Security supports protecting endpoints by using two forms of OAuth 2.0 Bearer Tokens

Что в переводе

Spring Security поддерживает защиту конечных точек с помощью двух форм токенов OAuth 2.0 Bearer Tokens

То есть стандартный starter реализует защиту, а в компоненте/статье я показываю способ преодолеть защиту )

Стартером, ссылку на который Вы дали, мы пользуемся.

Прекрасная статья! Очень хороший слог, легко читается. Спасибо.

Добротная статья, но вот скажите, чем keycloak лучше чем тот же зиккурат?)

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

pss. Как быть в случае когда надо что то, в бд какого-то сервиса защитить через стандартные внешние ключи и привязать к юзеру? Надо ли дублировать данные пользователя локально, или забить на внешние ключи и реализовать это программно? Буду благодарен ответу)

Здраствуйте,
Не смогу порассуждать/обсудить тему. Что такое Зиккурат не знаю, гуглинг по этому названию не предложил систему, которая бы соответствовала IAM системам. Приложите ссылку, пожалуйста, на материал. Посмотрю позже.

Если правильно понял, вопрос, то Вы больше про авторизацию - права на конкретные действия, конкретных пользователей или групп. При том, что еще в конктексте вопроса связь с БД. Предполагаю, должен быть какой-то процесс, в ходе которого будет понятно, кто пришел извне и какие у него права на работу с БД (просмотр/изменение/удаление). Видимо надо понять, кто это пришел, связать его с пользователем БД, который однозначно определит - есть ли у этого право что-то сделать/увидеть или нет.

Keycloak поможет связать это все в конкретное действие, то есть для пользователя определить права (в админке, сторонней таблице и т.д.). Flow остается таким же, как описано выше. Вы просто переложили заботу о правах и возможностях пользователя на отдельную систему, которая предоставит результат аудита прав этого пользователя.

Вы выполните действия, получите ответ и транслируете его в сервис. Если этого не делать, то, все действия рассредоточятся по нескольким системам. Это усложнит поддержку и развитие процесса.

Кратко так. Надеюсь правильно понял и корректно ответил на вопрос.


Sign up to leave a comment.