Частичный токен JWT при обновлении токена - PullRequest
0 голосов
/ 07 февраля 2019

В микросервисной архитектуре мы используем токены JWT из keycloak.Теперь мы хотели бы получить второй токен доступа с меньшими правами (меньше претензий / меньше ролей).Вариант использования: новый токен доступа должен предоставить его владельцу доступ только к одному документу в хранилище документов.Зачем?Чтобы ограничить урон, который кто-то может сделать, если он сможет украсть этот жетон.

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

Использование областей видимости не работает: список заданных областей оценивается только при входе в систему (поэтому в момент обновления токена я не могу принять список областей).

Я также пытался понять https://www.keycloak.org/docs/latest/authorization_services/index.html#_service_overview или RPT.Но, к сожалению, мне не хватает какой-то документации (и мои попытки провалились).

Есть ли другие идеи?Или, может быть, даже пример, показывающий, как это сделать?

Позже отредактируйте, чтобы сделать мой вопрос о RPT более явным: https://www.keycloak.org/docs/latest/authorization_services/index.html#_service_overview говорит:

... Службы авторизации Keycloak предоставляют расширения для OAuth2, позволяющие выдавать маркеры доступа на основе обработки всех политик, связанных с запрашиваемым ресурсом (ами) или областью (областями).Это означает, что серверы ресурсов могут обеспечивать доступ к своим защищенным ресурсам на основе разрешений, предоставленных сервером и удерживаемых маркером доступа.В Keycloak Authorization Services токен доступа с разрешениями для краткости называется токеном запрашивающей стороны или RPT.

Может ли такой токен доступа с разрешениями использоваться для нашей цели?

В моих экспериментах я мог получить токен с grant_type = urn: ietf: params: oauth: grant-type: uma-ticket.Но были некоторые проблемы:

  • Мне пришлось изменить некоторые настройки в keycloak, чтобы включить разрешения (до того, как было сказано «Клиент не поддерживает разрешения»).После того, как я внес эти изменения, мой обычный вызов входа в систему больше не будет работать (я мог проверить, пока мой токен был еще действителен).Мне пришлось поцарапать мою конфигурацию keycloak, чтобы продолжить работу.

  • Я не очень понимаю модель разрешений для использования этой функции

КонецПример конца-конца был бы полезен (те, что в документации Keycloak немного абстрактны).

1 Ответ

0 голосов
/ 16 февраля 2019

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

Keycloak - это сервер авторизации, совместимый с UMA 2.0, который обеспечивает большинство возможностей UMA.

КакНапример, рассмотрим пользователя Алиса (владелец ресурса), использующего службу интернет-банкинга (сервер ресурсов) для управления своим банковским счетом (ресурсом).Однажды Алиса решает открыть свой банковский счет Бобу (запрашивающая сторона), специалисту по бухгалтерскому учету.Однако у Боба должен быть доступ только к просмотру (области действия) учетной записи Алисы.

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

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

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

Затем использовать средства принудительного применения политики, чтобы активировать эту защиту:

Если сервер ресурсов защищенисполнителем политики он отвечает на запросы клиентов на основе разрешений, переносимых вместе с токеном-носителем.Как правило, когда вы пытаетесь получить доступ к серверу ресурсов с токеном-носителем, которому не хватает разрешений для доступа к защищенному ресурсу, сервер ресурсов отвечает кодом состояния 401 и заголовком WWW-Authenticate.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: UMA realm="${realm}",
    as_uri="https://${host}:${post}/auth/realms/${realm}",
    ticket="016f84e8-f9b9-11e0-bd6f-0021cc6004de"

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

Клиент запрашивает защищенный ресурс без отправки RPT

curl -X GET \
  http://${host}:8080/my-resource-server/resource/1bfdfe78-a4e1-4c2d-b142-fc92b75b986f

Сервер ресурсов отправляет ответ клиенту обратно с разрешением билета и параметром as_uri с расположением Keycloakсервер, куда билет должен быть отправлен для получения RPT.Сервер ресурсов отвечает билетом разрешения

HTTP/1.1 401 Unauthorized
WWW-Authenticate: UMA realm="${realm}",
    as_uri="https://${host}:${post}/auth/realms/${realm}",
    ticket="016f84e8-f9b9-11e0-bd6f-0021cc6004de"

Таким образом, клиент запрашивает ресурс, и ему выдается билет с указанием местоположения сервера Keycloak, чтобы обменять этот билет на RPT.Это клиент, выставляющий конечную точку токена, чтобы получить RPT:

curl -X POST \
  http://${host}:${port}/auth/realms/${realm}/protocol/openid-connect/token \
  -H "Authorization: Bearer ${access_token}" \
  --data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \
  --data "ticket=${permission_ticket} \
  --data "submit_request=true"

Это даст вам RPT, который действителен только для доступа к ресурсу, который вы запросили в первый раз.Скажите это:

{
  "authorization": {
      "permissions": [
        {
          "resource_set_id": "d2fe9843-6462-4bfc-baba-b5787bb6e0e7",
          "resource_set_name": "Hello World Resource"
        }
      ]
  },
  "jti": "d6109a09-78fd-4998-bf89-95730dfd0892-1464906679405",
  "exp": 1464906971,
  "nbf": 0,
  "iat": 1464906671,
  "sub": "f1888f4d-5172-4359-be0c-af338505d86c",
  "typ": "kc_ett",
  "azp": "hello-world-authz-service"
}

Вам также необходимо управлять доступом пользователей к своим ресурсам .Здесь это делается с помощью интерфейса администратора, но вам может потребоваться правильно настроить его из своего приложения, вызывая API Keycloak.

...