Определите из JWT, сгенерированного Keycloak, если пользователь авторизован для доступа к конкретному ресурсу - PullRequest
0 голосов
/ 26 сентября 2018

Документы Keycloak в OpenID Connect утверждают, что

Маркер доступа имеет цифровую подпись области и содержит информацию о доступе (например, сопоставления ролей пользователя) , что приложениеможно использовать для определения того, к каким ресурсам пользователю разрешен доступ в приложении .

Можно ли определить по токену доступа, возвращенному Keycloak после аутентификации, к каким ресурсам пользователь имеет доступ?Следуя инструкциям быстрого запуска keycloak по получению токена доступа OAuth2 , я получаю следующий JWT (без опущенных релевантных полей):

{
  "aud": "app-authz-springboot",
  "sub": "9c6c4a66-bb14-420f-a8af-3b2771266b38",
  "typ": "Bearer",
  "azp": "app-authz-springboot",
  "realm_access": {
    "roles": [
      "user"
    ]
  },
  "resource_access": {},
  "preferred_username": "alice"
}

Есть пустое поле

resource_access

Есть ли способ заполнить его ресурсами, к которым у пользователя есть доступ?Какова спецификация этого поля?Не удалось найти его в JWT RFC или Спецификация OpenID Connect

Я попытался другим способом, который работал:

  1. Получение токена доступа с использованием потока учетных данных пароля
  2. Обмен полученного токена на rpt с небольшим изменением с добавлением response_mode аргумент:

    curl -v -X POST \
      http://localhost:8180/auth/realms/spring-boot-quickstart/protocol/openid-connect/token \
      -H "Authorization: Bearer "$access_token \
      --data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \
      --data "audience=app-authz-rest-springboot" \
      --data "permission=Default Resource"
      --data "response_mode=decision"
    

Однако это решение требует отправки 2 запросов к Keycloak, чтобы определить, разрешен ли пользователю конкретный ресурс.

1 Ответ

0 голосов
/ 23 ноября 2018

Ваш сценарий использования не ясен.Стандартный механизм управления доступом к определенным ресурсам - роли , и вы получаете их как часть токена.Поэтому, если вы настраиваете доступ к своим конечным точкам, используя соответствующую модель ролей, и назначаете необходимые роли соответствующим пользователям, это будет контролировать доступ.На самом деле это способ управления доступом к URL-адресу /api/premium в примере SpringBoot , на который вы ссылаетесь в своем вопросе (сравните доступ по alice vs jdoe ).

Из вашего вопроса, как сейчас, не ясно, почему такой подход не работает для вас и почему вы хотите что-то еще.

...