如何将任何Azure Active Directory(AD)用户登录到共享本机应用程序,该应用程序连接到Office 365 Sharepoint Online API [英] How to sign in any Azure Active Directory (AD) user to a Shared Native app which connector to Office 365 Sharepoint Online APIs

查看:159
本文介绍了如何将任何Azure Active Directory(AD)用户登录到共享本机应用程序,该应用程序连接到Office 365 Sharepoint Online API的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

是否可以设置一个本机应用",供不同Azure帐户/目录上的用户使用,以便他们可以从其Office 365 Sharepoint Online获取数据?

Is it possible to set up a single "Native app" which can be used by users on different Azure accounts/directories so they can get data from their Office 365 Sharepoint Online?

我们可以使用"Web应用程序"来完成此工作,因为在您进行设置的Azure门户中,它具有多租户"选项,可以将其设置为是"-此注释支持以下内容:

We can get this working using a "Web app" because in the Azure portal where you set this up it has the "Multi-tenanted" option which can be set to Yes - the notes for this support this:

指定是否允许外部组织中的用户 授予您的应用访问其组织目录中数据的权限.这 控制仅影响授予访问权限的能力.它不影响 任何已被授予的访问权限.

Designates whether users in external organizations are allowed to grant your app access to data in their organization's directory. This control affects only the ability to grant access. It does not affect any access that has already been granted.

一些早期测试表明这确实有效. 但是这意味着使用必须嵌入在应用程序中的Oauth机密和此处的注释:

And some early testing suggests this does indeed work. However this implies using an Oauth secret which must be embedded in the app and the notes here:

https://docs.microsoft.com/zh-CN/azure/active-directory/develop/active-directory-protocols-oauth-code

状态(与应用机密有关):

State (in relation to the app secret):

....不应在本机应用程序中使用它,因为client_secrets 无法可靠地存储在设备上. Web应用程序和 Web API,能够安全地存储client_secret 在服务器端.

....It should not be used in a native app, because client_secrets cannot be reliably stored on devices. It is required for web apps and web APIs, which have the ability to store the client_secret securely on the server side.

对于本机应用程序,此处的文档:

For native apps, the docs here:

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

状态:

本地客户注册默认为多租户.你不 需要采取任何措施来制作本机客户端应用程序 注册多租户.

Native client registrations are multi-tenant by default. You don’t need to take any action to make a native client application registration multi-tenant.

这建议它们应该按照我们期望的方式工作-但是,当我们使用来自不在同一本地应用程序所在的Azure AD中的帐户的OAuth流进行测试时,我们在进行身份验证后会得到以下信息:

Which suggests they should work in the way we desire - however when we test this with OAuth flow from an account not in the same Azure AD where the native app was setup we get the following after authenticating:

AADSTS70001:在目录YYYYYYYYYYYYYYYYYYYYYY中找不到标识为"XXXXXXXXXXXXXXXXXXXXXX"的应用程序

因此看来这不起作用.目前看来,完成这项工作的唯一方法是创建一个Web应用程序,并将客户端ID和密码嵌入本机应用程序中.

So it appears this does not work. At present the only way it seems to make this work is to create a Web app and embed the client ID and secret in the native application.

有人在使用多租户本机应用程序方面取得了成功,还是对我做错了什么或可以尝试做任何想法/反馈?

Has anybody had success with multi-tenant native apps or any ideas/feedback on what I am doing wrong or could try?

更新我意识到这里有两个错误: *您实际上可以单击Azure中的清单"按钮并编辑原始JSON,更新"availableToOtherTenants"值以使其成为多租户. *我在OAuth流程中没有scope = user_impersonation.

UPDATE I realised there were two things wrong here: * You can actually click on the "Manifest" button in Azure and edit the raw JSON, updating the 'availableToOtherTenants' value to make it multi-tenant. * I didn't have the scope=user_impersonation in the OAuth flow.

现在看来,我们可以创建一个本机应用程序,其他组织/租户中的用户可以通过该应用程序进行身份验证.

Now it seems we can create a native app which users in other orgs/tenants can authenticate with.

更新2 确定,因此我们的应用程序现在可用于某些用户,但至少有一个正在获取:

UPDATE 2 OK so it turns out our app now works for some users but at least one is getting:

AADSTS65005:无效的资源.客户端已请求访问未在客户端应用程序注册的请求权限中列出的资源.客户端应用ID:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.来自请求的资源值: https://XXX.YYYYYY.com .资源应用程序ID:ZZZZZZZZZZZZZ.应用注册中的有效资源列表:00000002-0000-0000-c000-000000000000,00000003-0000-0ff1-ce00-000000000000.\ r \ n跟踪ID:KKKKKKKKKKKKKKKKKKK \ r \ n相关ID:CCCCCCCCCCCCCCCCCCCCCCC

AADSTS65005: Invalid resource. The client has requested access to a resource which is not listed in the requested permissions in the client's application registration. Client app ID: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA. Resource value from request: https://XXX.YYYYYY.com. Resource app ID: ZZZZZZZZZZZ. List of valid resources from app registration: 00000002-0000-0000-c000-000000000000, 00000003-0000-0ff1-ce00-000000000000.\r\nTrace ID: KKKKKKKKKKKKKKKKK\r\nCorrelation ID: CCCCCCCCCCCCCCCCCCC

我无法理解为什么如果两个用户都位于创建该应用程序的不同租户/Azure广告中,那么该用户为什么不能对另一个用户有效?

I can't see why it would work for one user but not another if both are in different tenant/Azure ADs to where the app is created.

推荐答案

如果您正在开发访问可以由您开发的多租户Web API的本机应用程序,则可以设置本机应用程序的添加clientId到具有knownClientApplications属性的Web应用程序清单的清单.这样,当其他租户的用户访问多租户Web API时,它也将向该租户注册本机应用程序.

If you were developing an native app which access the multi-tenant web API which also developed by you, you can set the add the clientId of native app to the manifest of web app's manifest with knownClientApplications property. So that when other tenant's users access the multi-tenant web API, it will also register the native app to their tenant.

请参考下面的代码示例,该示例演示Windows商店应用程序调用使用Azure AD保护的多租户Web API:

Refer the code sample below which demonstrates a Windows Store application calling a multi-tenant web API that is secured using Azure AD:

active-directory-dotnet-webapi-multitenant -windows-store

这篇关于如何将任何Azure Active Directory(AD)用户登录到共享本机应用程序,该应用程序连接到Office 365 Sharepoint Online API的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆