0

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

我的问题是：如何（或是否）可以使 Azure 中的容器级存储访问策略 在到期时恢复为较早的存储策略 (READ)，而不是“无访问”。“

MSDN 文章：Creating a Shared Access Signature in Java提供了一个良好的开端，但它还没有说明如何使用容器级存储策略来管理 Java 的共享访问策略。我正在学习 Java 和 SAS，因为我找不到类似于Azure Blob 的访问控制的Java 代码示例，所以我在下面包含了一小段 Java 代码来演示我的问题。

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

例如，假设有两个存储访问策略，名为“baxter”和“heath”，控制容器级别的权限，并且当容器的存储访问策略之前保存时，这两个策略都设置为 READ（仅） . 这些具有读取权限的初始策略将在几个月后到期。分配给“heath”或“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

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

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

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

但是，一旦达到过期时间，“baxter”字符串将失去对容器的所有权限，包括 READ 和 WRITE。但这不是我想要发生的。我需要分配给“baxter”策略的移动应用程序的权限才能恢复为 READ（仅限）。因为具有 WRITE 访问权限的 SAS 字符串允许任何人写入资源，最佳实践是保持开始时间和过期时间尽量短，不超过一个小时。对于我的特定应用程序，将权限设置为更长的时间是可以接受的。

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

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");         
    }
4

1 回答 1

1

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

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

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

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

根据需要，服务器应用程序可以将移动应用程序的子集提升为 READ 和 WRITE 权限，而无需发出新字符串。

即使您server这样做了，移动客户端如何理解现在他们也可以write，而不仅仅是read从那个云存储？我真的怀疑你的移动客户端总是试图默默地写，如果他们不能的话。

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

但是，如果存在这样的通信，那么没有什么可以阻止您提供具有RW权限（读取和写入）的新的更短寿命的 SAS。这个新的更短寿命的 SAS 甚至可以是stand aloneSAS，这意味着它不与任何存储的访问策略相关联，并且是专门为写入 blob 而发布的。

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

于 2013-03-26T10:59:39.153 回答