Как войти в систему любого пользователя Azure Active Directory (AD) в общее собственное приложение, которое соединяется с API-интерфейсами Office 365 Sharepoint Online

Можно ли настроить единое «собственное приложение», которое могут использовать пользователи в разных учетных записях / каталогах Azure, чтобы они могли получать данные из своих Office 365 Sharepoint Online?

Мы можем заставить это работать с помощью «веб-приложения», потому что на портале Azure, где вы это настроили, есть параметр «Многопользовательский», для которого можно задать значение «Да» - примечания для этого поддерживают следующее:

Определяет, могут ли пользователи во внешних организациях предоставлять вашему приложению доступ к данным в каталоге своей организации. Этот элемент управления влияет только на возможность предоставления доступа. Это не влияет на уже предоставленный доступ.

И некоторые ранние тесты показывают, что это действительно работает. Однако это подразумевает использование секрета Oauth, который должен быть встроен в приложение и примечания здесь:

https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-code

Состояние (относительно секрета приложения):

.... Его не следует использовать в собственном приложении, потому что client_secrets нельзя надежно хранить на устройствах. Это требуется для веб-приложений и веб-API, которые могут безопасно хранить client_secret на стороне сервера.

Для нативных приложений документы здесь:

https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-devhowto-multi-tenant-overview

Состояние:

Регистрации собственных клиентов по умолчанию являются мультитенантными. Вам не нужно предпринимать никаких действий, чтобы сделать регистрацию нативного клиентского приложения мультитенантной.

Это говорит о том, что они должны работать так, как мы желаем - однако, когда мы тестируем это с потоком OAuth из учетной записи не в том же Azure AD, где было настроено собственное приложение, после аутентификации мы получаем следующее:

AADSTS70001: приложение с идентификатором "XXXXXXXXXXXXXXXXXXXXXXX" не было найдено в каталоге YYYYYYYYYYYYYYYYYYY

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

У кого-нибудь были успехи с мультитенантными нативными приложениями или какие-либо идеи / отзывы о том, что я делаю неправильно или могу попробовать?

ОБНОВЛЕНИЕ. Я понял, что здесь есть две ошибки: * На самом деле вы можете нажать кнопку «Манифест» в Azure и отредактировать необработанный JSON, обновив значение «availableToOtherTenants», чтобы сделать его мультитенантным. * У меня не было scope = user_impersonation в потоке OAuth.

Теперь кажется, что мы можем создать собственное приложение, с помощью которого пользователи в других организациях / арендаторах могут аутентифицироваться.

ОБНОВЛЕНИЕ 2. Итак, оказалось, что наше приложение теперь работает для некоторых пользователей, но по крайней мере один из них получает:

AADSTS65005: недопустимый ресурс. Клиент запросил доступ к ресурсу, который не указан в запрошенных разрешениях при регистрации клиентского приложения. Идентификатор клиентского приложения: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA. Значение ресурса из запроса: https://XXX.YYYYYY.com. Идентификатор приложения-ресурса: ZZZZZZZZZZZ. Список допустимых ресурсов из регистрации приложения: 00000002-0000-0000-c000-000000000000, 00000003-0000-0ff1-ce00-000000000000. \ R \ nИдентификатор трассы: KKKKKKKKKKKKKKKKKK \ r \ nИдентификатор корреляции: SCPCCCCCCCCCCCCC

Я не понимаю, почему это будет работать для одного пользователя, но не для другого, если оба находятся в разных клиентах / Azure AD, где создано приложение.


person chrisb    schedule 09.03.2017    source источник


Ответы (1)


Если вы разрабатывали собственное приложение, которое обращается к мультитенантному веб-API, который также был разработан вами, вы можете добавить clientId собственного приложения в манифест манифеста веб-приложения с помощью свойства knownClientApplications. Таким образом, когда пользователи другого клиента получают доступ к мультитенантному веб-API, он также регистрирует собственное приложение для своего клиента.

См. Пример кода ниже, который демонстрирует, как приложение Магазина Windows вызывает мультитенантный веб-API, защищенный с помощью Azure AD:

active-directory-dotnet-webapi-multitenant-windows- магазин

person Fei Xue - MSFT    schedule 10.03.2017
comment
Мы пытаемся создать собственное приложение / коннектор, которое мы можем распространять, и каждый может использовать его для подключения к своим собственным данным sharepoint 365 (без необходимости настраивать собственное приложение OAuth пользователю). Смотрите мое обновление выше, но также интересно, если вы думаете, что это правильный подход. - person chrisb; 13.03.2017
comment
Извините за путаницу. Похоже, вы использовали Azure Конечная точка AD V2.0 (используйте scope вместо resource). Вот запрос, который у меня работает https://login.microsoftonline.com/common/oauth2/authorize?response_type=code&client_id={clientId}&redirect_uri={redirectUri}&prompt=login. Какой именно запрос вы использовали? - person Fei Xue - MSFT; 14.03.2017
comment
Привет! Мы не используем конечную точку V2.0. Введенный вами URL-адрес авторизации полностью совпадает с нашим, хотя у нас есть параметр состояния и запрос = согласие. Вы знаете, имеет ли какой-либо эффект включение scope = user_impersonation? В своих тестах я не заметил разницы. - person chrisb; 14.03.2017
comment
scope = user_impersonation не должен влиять на это. И OAuth 2.0, и OpenID подключаются к конечной точке Azure AD V1.0, нам нужно использовать параметр resource для получения токена доступа. Но поскольку приложение, которое вы разрабатывали, требовало разрешения на Office 365 SharePoint Online, убедитесь, что у клиента конечных пользователей также есть подписка на этот ресурс. Идентификатор приложения - это идентификатор клиента вашего пользовательского приложения или онлайн-ресурса SharePoint? - person Fei Xue - MSFT; 15.03.2017
comment
Идентификатор приложения совпадает с идентификатором собственного приложения, созданного в Azure AD. Мы используем resource = {SHAREPOINT_URL}, но только на последнем этапе преобразования кода OAuth в токен - кажется, не имеет значения, находится ли он в первом URL-адресе, который направляет пользователя на страницу входа. - person chrisb; 16.03.2017
comment
Можете ли вы войти в систему с запросом, как в моих комментариях к предварительному просмотру, используйте только _1 _, _ 2_, direct_uri и prompt? Он должен запросить страницу согласия, если вы впервые входите в приложение в этом клиенте. - person Fei Xue - MSFT; 17.03.2017
comment
Привет @Fei - Согласно моему комментарию выше, мы не используем конечную точку v2.0, но да, мы можем войти в систему только с помощью response_type, client_id, redirect_uri и prompt. И в соответствии с моим обновлением исходного вопроса после ручного обновления параметра availableToOtherTenants в манифесте мы добились определенного прогресса. Но теперь это работает только для некоторых пользователей, и по крайней мере один из них получает ошибку AADSTS65005, упомянутую в некоторых других сообщениях. Я обновлю исходный вопрос с пометкой об этом. - person chrisb; 09.04.2017
comment
Также Фей - я только что заметил в вашем исходном ответе, что вы упомянули `` доступ к мультитенантному веб-API, который также разработан вами '' - не уверен, насколько это важна, но мы не пытаемся получить доступ к веб-API, разработанному нами, мы пытаются предоставить приложение, которое обращается к Office 365 API Sharepoint Online API. - person chrisb; 09.04.2017
comment
Для ошибки AADSTS65005 вам необходимо предоставить ресурс в запрашиваемом вами приложении при регистрации приложения. - person Fei Xue - MSFT; 11.04.2017