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

Question

У меня есть служба, зарегистрированная как многопользовательский веб-API в клиенте AAD «A».Клиент зарегистрирован как веб-приложение в другом клиенте AAD «B».Вопрос в том, нужна ли мне какая-либо дополнительная настройка на портале Azure, чтобы клиентское приложение в клиенте «B» могло успешно обращаться к веб-API в клиенте «A» (проверка подлинности приложения для приложения)?Поддерживает ли AAD такой сценарий?В настоящее время я получаю код состояния Несанкционированный в качестве ответа от службы, когда служба развернута в Azure.

Служба в клиенте A не отображается, когда я пытаюсь вручную управлять разрешениями для клиентского приложения в клиенте B. Является ли этот шаг необходимым или мне не хватает какой-либо конфигурации?

Сервис построен на приложении MVC asp.net и использует схему аутентификации канала-носителя JWT.Клиент успешно получает свой токен от своего собственного клиента AAD.Так что это не похоже на проблему аутентификации.Что касается обслуживания, я добавил клиента в качестве одного из допустимых эмитентов токенов.

Я не уверен, что субъект клиента службы для приложения-службы создается автоматически в клиенте клиента (до сих пор страница согласия никогда не отображалась).

Answer 1

Сценарий поддерживается.Вам просто нужно сначала дать согласие на API-интерфейс от арендатора B. Прежде чем он появится в списке.

Вы можете определить разрешения для своего приложения в Web API как обычно ( проверьте здесь ).

Затем вы можете получить согласие на API, открыв URL-адрес, подобный следующему:

https://login.microsoftonline.com/tenant-b-id/oauth2/authorize?client_id=your-api-client-id&response_type=code&redirect_uri=reply-url-defined-on-api&prompt=admin_consent

Вам нужно заменить 3 значения на ваше:

• tenant-b-id : идентификатор каталога для арендатора B
• your-api-client-id : идентификатор приложения / идентификатор клиента вашего APIв клиенте A
• response-url-define-on-api : URL-адрес ответа в кодировке URL, определенный в вашем API в клиенте A (например, https%3A%2F%2Flocalhost%2F)

Это должно привести к созданию субъекта службы в арендаторе B для API, что позволит вам назначать разрешения приложений для приложений в арендаторе B.