Должен ли клиент веб-службы без настольного клиента быть динамически зарегистрированным клиентом OIDC - или что-то еще? - PullRequest
Новая
       8

Должен ли клиент веб-службы без настольного клиента быть динамически зарегистрированным клиентом OIDC - или что-то еще?

0 голосов
/ 31 августа 2018

Моя установка имеет следующее:

  • Это мультитенантная система, поэтому в набор пользовательских заявок входит tenant_id, который однозначно идентифицирует арендатора, которому принадлежит пользователь.
  • Веб-сервис на основе IdentityServer4 (который предоставляет сервисы OAuth2 / OpenID Connect): https://identity.example.com.
  • Отдельный веб-сервис (RESTful web-api): https://random-number-generator-service.example.com.
  • Безголовая программа (служба Windows), которая запускается на локальных компьютерах во многих местах: RandomNumberConsumer.exe. Эта программа использует random-number-generator-service в контексте tenant_id, поэтому пользователь должен каким-то образом проходить проверку подлинности, но в противном случае программа не заботится о деталях пользователя, только сведениях об арендаторе пользователя.

Я понимаю, что это означает, что и random-number-generator-service , и RandomNumberConsumer.exe являются "клиентами".

В IdentityServer все клиентское программное обеспечение должно быть зарегистрировано (либо статически в виде жестко закодированного списка Client экземпляров объекта, либо с помощью некоторой динамической регистрации с использованием базы данных для хранения сведений о клиенте. Очевидно, random-number-generator-service будет иметь статическую регистрацию, но как RandomNumberConsumer.exe также зарегистрироваться?

Некоторые опции:

  1. Добавить новое веб-приложение, в которое пользователи могут войти, используя веб-браузер, и зарегистрировать свою установку RandomNumberConsumer.exe (которая добавляет новую регистрацию Client в клиентскую базу данных identity.example.com, дополненную секретом клиента ) затем пользователь вручную копирует и вставляет секрет клиента в файл конфигурации RandomNumberConsumer.exe. Внутренняя база данных сопоставляет каждую регистрацию клиента с tenant_id. Это имеет то преимущество, что позволяет отдельному клиенту отзывать доступ, но требует от пользователя выполнения шагов ручной настройки, которые нежелательны.
  2. Регистрация одного клиента на RandomNumberConsumer.exe без секрета клиента, но клиентскому приложению необходим компонент с графическим интерфейсом, с помощью которого он может аутентифицировать пользователя и сохраняет связанные с ним access_token и refresh_token пользователя в своей локальной конфигурации. Это имеет преимущество, заключающееся в том, что пользовательский интерфейс намного проще (поскольку пользователь откроет программу RandomNumberConsumerConfiguration.exe, которая затем откроет веб-браузер для доступа к странице аутентификации и получит данные, используя redirect_uri с временным localhost или значение пользовательской схемы URI), но это означает, что экземпляр RandomNumberConsumer.exe связан с отдельным пользователем-человеком, когда мы хотим, чтобы он ассоциировался только с арендатором.

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

1 Ответ

0 голосов
/ 01 сентября 2018

Каждый экземпляр клиента должен иметь свой собственный идентификатор. random-number-generator-service должен иметь один идентификатор (даже если он работает в веб-ферме).

RandomNumberConsumer.exe устанавливается на разных компьютерах вне домена, поэтому должен иметь уникальный идентификатор для каждой установки.

Клиент не имеет никакого отношения к пользователю, так как требование sub отсутствует. Единственный раз, когда клиент включает требование sub , это когда он действует от имени (и с согласия) пользователя. Это может иметь место для random-number-generator-service, но не для RandomNumberConsumer.exe, когда нет взаимодействия с пользователем (так как это служба Windows) и согласие не требуется, поскольку оно дается, когда пользователь запрашивает установку.

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

  1. Пользователь запрашивает установку программы. После утверждения клиент создается и присоединяется к арендатору (ClientClaims) на основе пользователя.
  2. Пользователь начинает загрузку установщика и получает идентификатор / секрет (на экране, электронная почта).
  3. Пользователь начинает установку, и на одном из шагов пользователь должен ввести идентификатор / секрет. Это приемлемо, так как это довольно распространено при установке программного обеспечения.

Это имеет те преимущества, которые вы хотите, и требует от пользователя минимальных шагов.

Если у службы есть больше параметров конфигурации, и вы хотите предоставить пользователю пользовательский интерфейс для сохранения параметров, добавьте программу настройки в установщик. Это довольно распространено для маршрутизаторов и принтеров. Пользователю не нужно входить в систему, поскольку он работает локально (сайт localhost). Вы можете добавить ссылку для браузера как ярлык.

...