java - 使用Java控制Azure容器级访问策略

Question

我正在尝试设计一个在本地服务器上运行的Java应用程序，该应用程序管理对存储在Windows Azure中的Blob的访问权限。多个移动应用程序（也用Java编写）使用云存储资源，这些应用程序需要对托管在云中的单个Blob容器进行读取访问，有时需要临时写入访问。我正在使用Windows Azure Plugin for Eclipse with Java by Microsoft Open Technologies。

我的问题是：如何使Azure中的容器级stored access policies在到期时恢复为较早的存储策略（READ），而不是“无权访问”。 “

MSDN文章：Creating a Shared Access Signature in Java提供了一个良好的开端，但是对于如何使用容器级存储的策略来管理Java共享访问权限，它还没有说太多。我正在学习Java和SAS，并且由于找不到类似于Access Control for Azure Blobs的Java代码示例，因此我在下面提供了一小段Java代码来演示我的问题。

服务器应用程序检索用于连接到Azure存储的私有存储连接字符串。获取云存储帐户并创建一个云Blob客户端。获取对容器的引用，并创建一个尚不存在的容器。 （请注意，容器名称必须为小写。）然后，下载容器的当前权限。 （一个容器最多可以保存五个容器级别的存储访问策略。）

例如，假设有两个存储的访问策略，分别名为“ baxter”和“ heath”，用于控制容器级别的权限，并且当先前保存了容器的存储访问策略时，这两个策略均设置为READ（仅） 。这些具有读取权限的初始策略被设置为在几个月后过期。然后，分配给“健康”或“ baxter”策略的移动应用程序首先通过uri字符串对sascontainer6中存储的blob进行读取访问，类似于：

http://grassy.blob.core.windows.net/sascontainer6/image4.jpg?sr=c&sv=2012-02-12&sig=5G7EOgiYYNEGmw2Y0T4IUgt%2FzTnmYpaxWfB5nEira08%3D&si=baxter

http://grassy.blob.core.windows.net/sascontainer6/image4.jpg?sr=c&sv=2012-02- 12&sig=llUoAg2PvFUfhO28ncrlheh2RRJdb7smQEX6nO8xoCk%3D&si=heath

根据需要，服务器应用程序可以将移动应用程序的子集提升为读取和写入权限，而不必发出新的字符串。它可以通过修改与容器一起保存的“ baxter”策略来实现。控件的“粒度”处于策略级别，并且策略更新使分配给“ baxter”策略的所有移动应用程序都可以在容器中写入（或覆盖）blob。分配给“ heath”策略的移动应用程序将继续以类似的方式，服务器应用程序可以撤销分配给特定策略的应用程序对容器的所有访问。

在更改策略之前，服务器应用程序确保已关闭对容器的公共访问。它将当前时间指定为开始时间，并且将访问时间指定为开始时间之后的一小时。它为新策略设置了READ和WRITE权限。最后，现有的“ baxter”策略将被新策略覆盖。

generateSharedAccessSignature方法可以获取“ baxter”和“ heath”策略的共享访问签名（SAS）。更改策略中保存的权限不应更改SAS，使用上述uri字符串的应用程序应可以工作到指定的到期时间。

但是，一旦达到到期时间，“ baxter”字符串将失去对容器的所有权限，包括READ和WRITE。但这不是我想要发生的事情。我需要分配给“ baxter”策略的移动应用程序的权限才能还原为READ（仅）。由于具有WRITE访问权限的SAS字符串使任何人都可以写入资源，因此最佳做法是保持开始时间与启动时间之间的时间间隔。有效期越短越好，不超过一个小时。将较长的读取权限设置为我的特定应用程序是可以接受的。

我的问题是：如何（或是否）使用Azure中的容器级共享访问策略来允许令牌（即上面显示的“ baxter”字符串）恢复为备用策略（即“ READ”）而不是“无权访问” 。”

public static void main(String[] args) throws InvalidKeyException, URISyntaxException, StorageException 
    {           
    Account creds = new Account();              
    final String storageConnectionString = creds.getstorageconnectionstring();
    CloudStorageAccount storageAccount = CloudStorageAccount.parse(storageConnectionString);
    CloudBlobClient blobClient = storageAccount.createCloudBlobClient();
    CloudBlobContainer container = blobClient.getContainerReference("sascontainer6");
    container.createIfNotExist();
    BlobContainerPermissions containerPermissions = container.downloadPermissions();
    containerPermissions.setPublicAccess(BlobContainerPublicAccessType.OFF);
    SharedAccessBlobPolicy policy = new SharedAccessBlobPolicy();
    GregorianCalendar calendar = new GregorianCalendar(TimeZone.getTimeZone("UTC"));
    calendar.setTime(new Date());
    policy.setSharedAccessStartTime(calendar.getTime());
    calendar.add(Calendar.HOUR, 1);
    policy.setSharedAccessExpiryTime(calendar.getTime());
    policy.setPermissions(EnumSet.of(SharedAccessBlobPermissions.READ, SharedAccessBlobPermissions.WRITE));
    containerPermissions.getSharedAccessPolicies().put("baxter", policy);            
    container.uploadPermissions(containerPermissions);
    String sas = container.generateSharedAccessSignature(new SharedAccessBlobPolicy(),"baxter");         
    String sasex = container.generateSharedAccessSignature(new SharedAccessBlobPolicy(),"heath");         
    }

Answer 1

您对SAS一起对容器级别访问策略表现出了很好的理解。所有的解释导致一个非常具体的问题：


我的问题是：如何（或是否）采用容器级共享访问策略
Azure可用于允许令牌（即显示的“ baxter”字符串
以上）恢复为备用策略（即“读取”），而不是
“无法访问。”


不幸的是，答案是“否”。您无法定义fallback容器级别策略过期时发生的情况。一旦过期，就结束了。与之关联的SAS不能对关联的资源执行任何操作。您必须从服务器端代码使用新的权限和新的有效日期再次显式覆盖它。

但是我想挑战一下您的概念架构。您有一个声明：


根据需要，服务器应用程序可以提升一部分移动设备
应用程序同时具有读取和写入权限，而不必
发出一个新的字符串。


即使您的server这样做了，移动客户端如何理解现在他们也可以write，而不是仅来自该云存储的read？我真的怀疑您的移动客户端是否总是尝试默默地写死。

我的猜测是，在移动客户端意识到它可以写入云存储之前，存在某种server-to-mobile-client通信。如果没有这样的通信，那么恕我直言，有些东西就坏了。

但是，如果存在此类通信，则没有任何事情会阻止您提供具有RW权限（读取和写入）的新的较短寿命的SAS。这个新的较短的活动SAS甚至可以是stand alone SAS，这意味着它与任何存储的访问策略都不相关，并且是专门出于写入blob的原因而发行的。

我的另一个猜测是，您希望避免通过电线发送SAS以避免man-in-the-middle类型的攻击。而是希望在应用程序中预先配置SAS。如果是这种情况，我建议您为读写设置单独的访问策略。您可以放心地使用expired访问策略进行写入，并仅在需要时使其有效。您的设备现在将具有4个SAS URI，而不是2个，但它（该设备）将准确地知道哪个策略是“只读”，以及使用哪个策略可以尝试写入。请注意，即使过期，“写”访问策略仍与容器关联，不会被删除。因此，您只需要在下次激活它时对其进行更新。