Azure Blob存储:多个容器的共享访问签名? [英] Azure blob storage: Shared access signature for multiple containers?

问题描述

我正在创建一个将在Azure中托管的应用程序.在此应用程序中，用户将能够上传他们自己的内容.他们还将能够配置将能够读取其文件的其他受信任的应用程序用户的列表.我正在尝试弄清楚如何构造存储.

I'm creating an application that will be hosted in Azure. In this application, users will be able to upload their own content. They will also be able to configure a list of other trusted app users who will be able to read their files. I'm trying to figure out how to architect the storage.

我认为我将创建一个以每个用户的应用程序ID命名的存储容器，他们将能够在此上传文件.我的问题与如何授予对用户应有权访问的所有文件的读取访问权限有关.我一直在阅读有关共享访问签名的信息，它们似乎很适合我想要实现的目标.但是，我正在评估向用户授予访问权限的最有效方法.我认为存储的访问策略可能会有用.但具体来说:

I think that I'll create a storage container named after each user's application ID, and they will be able to upload files there. My question relates to how to grant read access to all files to which a user should have access. I've been reading about shared access signatures and they seem like they could be a great fit for what I'm trying to achieve. But, I'm evaluating the most efficient way to grant access to users. I think that Stored access policies might be useful. But specifically:

我可以使用一个共享访问签名(或存储的访问策略)来授予用户访问多个容器的权限吗?我发现了一条我认为非常相关的信息:

Can I use one shared access signature (or stored access policy) to grant a user access to multiple containers? I've found one piece of information which I think is very relevant:

http://msdn.microsoft.com/en-us/library/windowsazure/ee393341.aspx

容器，队列或表最多可以包含5个存储的访问策略.每个策略可以由任意数量的共享访问签名使用."

"A container, queue, or table can include up to 5 stored access policies. Each policy can be used by any number of shared access signatures."

但是我不确定我是否理解正确.如果某个用户与其他20个人建立了联系，我可以授予他或她20个特定容器的访问权限吗?当然，我可以生成二十个单独的存储的访问策略，但这似乎不是很有效，并且当他们首次登录时，我计划显示其所有其他受信任的应用程序用户的内容摘要，这相当于要求一次有20个签名(如果我理解正确的话).

But I'm not sure if I'm understanding that correctly. If a user is connected to 20 other people, can I grant him or her access to twenty specific containers? Of course, I could generate twenty individual stored access policies, but that doesn't seem very efficient, and when they first log in, I plan to show a summary of content from all of their other trusted app users, which would equate to demanding 20 signatures at once (if I understand correctly).

感谢您的任何建议... -奔

Thanks for any suggestions... -Ben

推荐答案

由于每个用户都有一个容器(目前，我将一个用户与您所说的用户应用程序ID等同起来)，这意味着您将有一个存储帐户，该帐户可以为许多用户包含许多不同的容器.如果想让应用程序能够上载到一个特定的容器，同时又要从许多两个选项中读取内容.

Since you are going to have a container per user (for now I'll equate a user with what you called a user application ID), that means you'll have a storage account that can contain many different containers for many users. If you want to have the application have the ability to upload to only one specific container while reading from many two options come to mind.

首先:创建一个API，该API可以处理所有请求.在API的后面，您的代码将具有对整个存储帐户的完全访问权限，因此您的业务逻辑将确定它们做什么以及没有访问权限.这样做的好处是您根本不必创建共享访问签名(SAS).您的应用只知道如何与API通讯.您甚至可以通过并行调用从应用程序的一次调用中获取来自各个容器的内容，从而组合他们在内容摘要中可以看到的数据.缺点是您现在托管此API服务，该服务必须代理所有这些调用.如果您选择该路线，仍然需要API服务来生成SAS，但是仅需要生成SAS即可，并且客户端应用程序将直接通过Windows Azure存储服务进行调用，从而承担了负载，这将减少资源您真正需要的.

First: Create a API that lives somewhere that handles all the requests. Behind the API your code will have full access to entire storage account so your business logic will determine what they do and do not have access to. The upside of this is that you don't have to create Shared Access Signatures (SAS) at all. Your app only knows how to talk to the API. You can even combine the data that they can see in that summary of content by doing parallel calls to get contents from the various containers from a single call from the application. The downside is that you are now hosting this API service which has to broker ALL of these calls. You'd still need the API service to generate SAS if you go that route, but it would only be needed to generate the SAS and the client applications would make the calls directly with the Windows Azure storage service bearing the load which will reduce the resources you actually need.

第二个:走SAS路线并根据需要生成SAS，但这会有些棘手.

Second: Go the SAS route and generate SAS as needed, but this will get a bit tricky.

每个容器最多只能创建五个存储访问策略.对于这五个中的一个，您为容器的所有者"创建了一个策略，该策略为他们提供了读取和写入权限.现在，由于您允许其他人向其他人授予读取权限，因此除非您为读取重复使用相同的策略，否则您将遇到策略计数限制，但是如果用户从某人中删除某人，您将无法撤消该策略受信任的"读者名单.例如，如果我将Bob和James的权限都授予了我的容器，并且他们都被授予了Read SAS的副本，如果我需要删除Bob，则必须取消他们共享的Read Policy并重新发布新的Read SAS给詹姆斯.但这并不是什么大问题，因为该应用程序可以检测到何时不再具有权限并请求更新的SAS.

You can only create up to five Stored Access Policies on each container. For one of these five you create one policy for the "owner" of the container which gives them Read and write permissions. Now, since you are allowing folks to give read permissions to other folks you'll run into the policy count limit unless you reuse the same policy for Read, but then you won't be able to revoke it if the user removes someone from their "trusted" list of readers. For example, if I gave permissions to both Bob and James to my container and they are both handed a copy of the Read SAS, if I needed to remove Bob I'd have to cancel the Read Policy they shared and reissue a new Read SAS to James. That's not really that bad of an issue though as the app can detect when it no longer has permissions and ask for the renewed SAS.

无论如何，您仍然希望策略短暂存在.如果我从值得信赖的读者中删除了Bob，那么我非常希望他立即被切断.这意味着您将大量返回更新的SAS，并重新创建签名的访问签名，这降低了签名的访问策略的实用性.这确实取决于您的胃口，即您打算允许该政策生效多长时间，以及您希望某人在不受信任的情况下"被切断的速度有多快.

In any case you still kind of want the policies to be short lived. If I removed Bob from my trusted readers I'd pretty much want him cut off immediately. This means you'll be going back to get a renewed SAS quite a bit and recreating the signed access signature which reduces the usefulness of the signed access policies. This really depends on your stomach of how long you were planning on allowing the policy to live and how quickly you'd want someone cut off if they were "untrusted".

现在，更好的选择可能是创建临时签名.您可以实际拥有任意数量的临时签名，但是它们不能被撤销，并且最多只能使用一小时.因为您会让他们短暂存在，所以撤销或取消的期限不应该成为问题.遵循这条路线将意味着您需要让应用程序返回以根据需要获取它们，但是鉴于我上面提到的有关有人被删除并且您希望SAS用尽的内容，这可能没什么大不了的.正如您所指出的那样，这确实增加了事情的复杂性，因为您生成了很多SAS.但是，由于这些都是临时的，因此您实际上不需要跟踪它们.

Now, a better option could be that you create Ad-hoc signatures. You can have as many Ad-hoc signatures as you want actually, but they can't be revoked and can at most last one hour. Since you'd make them short lived the length or lack of revocation shouldn't be an issue. Going that route will mean that you'd be having the application come back to get them as needed, but given what I mentioned above about when someone is removed and you want the SAS to run out this may not be a big deal. As you pointed out though, this does increase the complexity of things because you're generating a lot of SASs; however, with these being ad-hoc you don't really need to track them.

如果您打算走SAS路线，建议您的API根据需要生成临时的.它们的持续时间不应超过几分钟，因为人们可以删除对容器的权限，而您要做的只是减少实际执行上载和下载的托管服务的负载.同样，用于处理某人可以看到的容器的所有逻辑仍然在您的API服务中，并且应用程序仅获得可以在短时间内使用的签名.

If you were going to go the SAS route I'd suggest that your API be generating the ad-hoc ones as needed. They shouldn't last more than a few minutes as people can have their permissions to a container removed and all you are trying to do is reduce the load on hosted service for actually doing the upload and download. Again, all the logic for handling what containers someone can see is still in your API service and the applications just get signatures they can use for small periods of time.

这篇关于Azure Blob存储:多个容器的共享访问签名?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！