Уточнение потока учетных данных клиента Keycloak

Я использую сервер Keycloak для реализации системы единого входа. Я могу получить токен доступа для конкретного клиента с помощью потока client_credentials.

Однако, по моим наблюдениям, токен доступа предоставляется внутренней служебной учетной записи клиента. Я хочу получить токен доступа для других пользователей, присутствующих в области, указав некоторый дополнительный параметр для конечной точки токена .

Ниже приведен текущий запрос, который я отправляю конечной точке токена с помощью расширения Postman Chrome:

POST http://localhost:8080/auth/realms/<realm>/protocol/<protocol>/token

x-www-form-urlencoded

grant_type        client_credentials
client_id         <client_id>
client_secret     <client_secret>

Пожалуйста, дайте мне знать, если это возможно. Кроме того, я хотел бы сообщить, что я совершенно не знаком с протоколами Keycloak и openid-connect.


keycloak openid-connect
person Community    schedule 20.01.2017    source источник

Ответы (1)


arrow_upward
19
arrow_downward

Я думаю, вы неправильно понимаете некоторые концепции Oauth прямо здесь. Грант client_credentials должен использоваться только для самой службы, чтобы предоставить доступ к определенному ресурсу. Представьте себе такой сценарий:

Конечный пользователь -> Служба Документов -> Репозиторий Документов

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

Однако службе документации требуется полный доступ к репо. Он может получить доступ к любому запрошенному документу. Решение состоит в том, чтобы предоставить службе документации роль учетной записи службы, скажем DOC_MANAGER, и выполнить проверку репо для этой роли при запросе ресурса. Служба аутентифицируется с помощью client_credentials и получает доступ к ресурсу как службе.

Но конечный пользователь выполнит стандартный вход в систему, используя поток кода авторизации, например, и получить доступ к документу через сервис. Служба проверит наличие другой роли, скажем, DOC_USER, и проверит, есть ли у пользователя доступ к этому конкретному ресурсу, прежде чем перейти к репо.

Подробнее об учетных записях службы keycloak можно узнать здесь.

person Xtreme Biker    schedule 21.01.2017
comment
Большое спасибо за объяснение. Это очень понятно и понятно. У меня самого была подобная мысль. Я спросил об этом, потому что это требование, данное мне. Теперь я подтвердил, что данное мне требование не имеет никакого смысла. :-) - person ; 23.01.2017
comment
Последняя ссылка привела меня на страницу 404: / - person Sèb; 03.10.2017
comment
@ Сэб исправлено ;-))) - person Xtreme Biker; 03.10.2017