Мы используем Azure Active Directory для защиты наших размещенных API Azure.Эти API используются приложениями Angular, размещенными в Azure.Mocst API реализован в виде ASP.NET WebAPI, некоторые из них теперь реализованы с использованием функций Azure.
Мы защищали наши приложения таким образом последние пару лет, и у нас не было никаких проблем.Мы уже предоставляли доступ к одному приложению на основе токенов для другого, добавляя их в разрешенную аудиторию, и это работало нормально.В настоящее время мы сталкиваемся с проблемой при реализации нового сценария.
Проблема
У нас есть два приложения: текущее ( cur ) и целевое ( tar ).Все наши пользователи могут войти на cur .Бэкэнд для cur получает токен для доступа к tar на основе токена, который пользователь получил за cur .Это работает для пользователей, поддерживаемых Azure Active Directory, нашей или федеративной.Как только пользователи входят в систему, которые не поддерживаются Azure Active Directory (что означает, что они поддерживаются учетной записью Microsoft), получение токена для tar завершается с ошибкой AADSTS50000: There was an error issuing a token,
Контекст
Наши приложения размещаются в другом клиенте AAD, чем те, где зарегистрированы наши пользователи и приложения.Регистрация пользователей и приложений в одном и том же клиенте AAD.Мы не думаем, что это проблема, поскольку конфигурация работает для учетных записей, поддерживаемых AAD.
Мы используем AuthenticationContext.AcquireTokenAsync (String, ClientCredential, UserAssertion) , чтобы получить токен для доступа к tar со следующими параметрами:
- ID tar application
- ID и ключ cur
- Токен текущего пользователя для cur
Мы видим одно существенное различие между исходными токенами для учетных записей с поддержкой AAD и учетных записей с поддержкой учетных записей Microsoft: поле IDP (IdentityProvider) отличается.Для учетных записей, поддерживаемых учетной записью Microsoft, IDP составляет live.com.Для учетных записей с поддержкой AAD это https://sts.windows.net/<guid>.
Мы создали несколько тестовых учетных записей, как в нашей AAD, так и во внешних, чтобы убедиться, что это не проблема, связанная с нашими существующими учетными записями пользователей.Использование различных конфигураций для наших AuthenticationContext или ClientCredential не решает проблему.
Есть идеи?