Как безопасно реализовать мультитенантный доступ из службы Windows к общедоступному WebApi

Я пытаюсь понять, как реализовать службу Windows (Headless), которую можно настроить для взаимодействия с нашим WebApi в мультитенантном сценарии. Ближайший пример, который я смог найти, был опубликован здесь Вызов веб-API в демоне или длинном -запуск. Проблема с этим образцом заключается в том, что он не показывает, как вы будете действовать в многопользовательском сценарии. Если вы используете один и тот же AppKey для каждого клиента, будет ли возможно выдать себя за другого клиента, если кто-то решит искать в приложении ClientID и AppKey? Похоже, что один из способов обойти это - создать новый AppKey для каждого клиента, который присоединяется к нашему сервису. Этот ключ приложения необходимо предоставить службе Windows в качестве параметра конфигурации при установке службы заказчиком. Это правильный подход? Это не кажется правильным направлением, поскольку на портале AAD не будет очевидно, какой ключ AppKey связан с каким клиентом. Похоже, вам придется справиться с этим самостоятельно. Я знаю, что вы должны передать идентификатор клиента как часть полномочий, но эти идентификаторы не похожи на AppKey или пароли. Какой правильный подход для этого сценария?

Я также смотрю на этот образец Создание мультитенантного веб-API, защищенного Azure AD. К сожалению, этот образец является приложением для магазина Windows. У него есть пользовательский интерфейс, поэтому он может выполнять типичный танец согласия с AAD. Очевидно, что служба Windows не может использовать этот подход. Я могу самостоятельно разместить веб-приложение в службе Windows, заставить пользователя пройти процесс согласия хотя бы один раз, поэтому токен будет кеширован, как в этом примере. Однако что мне использовать в качестве RedirectUrl? Это не приложение для магазина Windows, поэтому я не могу использовать

WebAuthenticationBroker.GetCurrentApplicationCallbackUri();

Мне не ясно, поддерживается ли этот сценарий.


azure windows c# azure-active-directory adal
person Steve W.    schedule 15.12.2015    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Ваш последний метод - это то, что вам нужно. Не создавайте один ключ для каждого арендатора, это будет кошмаром для управления ключами.

Создайте одно приложение и попросите его запрашивать «разрешения приложения», необходимые вашей службе. Прежде чем ваша служба сможет получить токен в данном клиенте, вам действительно нужно будет получить интерактивное согласие от администратора клиента, который предоставит авторизацию, необходимую вашему приложению. Тогда ваше приложение сможет запрашивать и получать токены, как в статье о демонах, на которую вы ссылаетесь.

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

person dstrockis    schedule 21.07.2016
comment
Разве это не проблема, что каждый арендатор будет использовать один и тот же идентификатор клиента + секрет клиента для получения токенов? Разве это не упростило бы арендаторам выдавать себя друг за друга? - person Adrian Hofman; 21.07.2016

arrow_upward
0
arrow_downward

Я бы рекомендовал реализовать веб-токены JSON (JWT) - см. Веб-токен JSON в веб-API ASP.NET 2 с использованием Owin. Затем вы можете использовать токены обновления JWT, которые, по сути, позволяют пользователю оставаться аутентифицированным навсегда, но они могут быть отозванным.

person viperguynaz    schedule 15.12.2015
comment
Я могу получить токен с помощью ADAL на сервере, используя текущего пользователя, вошедшего в систему, встроить его в установочный пакет службы Windows, загруженный с сервера. Однако не похоже, что ADAL поддерживает идею использования существующего токена. Было бы действительно неплохо иметь возможность использовать ADAL для обработки обновления токена. - person Steve W.; 16.12.2015