如何命名 Windows Azure SharedAccessBlobPolicy 键

我正在尝试让一些第三方访问我的天蓝色 Blob 容器。 我希望他们能够读取容器内的任何文件。

我在遵循以下指导后使用以下代码http://www.windowsazure.com/en-us/documentation/articles/storage-dotnet-shared-access-signature-part-2/ http://www.windowsazure.com/en-us/documentation/articles/storage-dotnet-shared-access-signature-part-2/

但是我想为不同的第三方创建不同的密钥。

例如我将与 companyA 分享的一把钥匙 我将与 companyB 分享的另一个密钥

无论如何我可以命名这些键，例如密钥公司A、密钥公司B

我想给它们起一个合理的名称的原因是，如果您与公司的协议到期，我可以搬进去并删除该密钥。

public Void CreateAccessKeyBlob()
{

    const string accountName = "myAccountName";
    const string primaryAccessKey = "myAccessKey";

    var conn = string.Format("DefaultEndpointsProtocol=https;AccountName={0};AccountKey={1}", accountName, primaryAccessKey);

    var storageAccount = CloudStorageAccount.Parse(conn);

    //Create the blob client object.
    var blobClient = storageAccount.CreateCloudBlobClient();

    //Get a reference to a container to use for the sample code, and create it if it does not exist.
    var container = blobClient.GetContainerReference("myContainer");

    var sasConstraints = new SharedAccessBlobPolicy
    {
        SharedAccessExpiryTime = DateTime.UtcNow.AddYears(50),
        Permissions = SharedAccessBlobPermissions.Read | SharedAccessBlobPermissions.List
    };

    //Generate the shared access signature on the container, setting the constraints directly on the signature.
    var sasContainerToken = container.GetSharedAccessSignature(sasConstraints);

    Console.ReadLine();
}

不幸的是，我认为您对共享访问签名的方式有一些误解。

共享访问签名（简单地说）是访问一组资源的数字签名权限单。签名基于作为查询字符串参数包含在 URL 中的参数（区域、访问类型、开始/结束时间等）。然后，我们生成并附加一个“签名”，它是这些参数的哈希值和存储帐户的“密钥”。

因此，两个签名之间唯一真正的区别是其创建时使用的参数。

签名一旦生成，就无法撤销。但是，如果签名基于存储帐户访问策略（基本上是分配共享访问签名参数的快捷方式），则如果删除该策略，签名将无效。这是因为策略是与签名关联的参数，一旦删除该策略，签名当然无法得到验证。

现在您可能认为可以为每个客户设置不同的策略。但是...可以与存储帐户关联的策略数量有限制（我上次检查的是 5 个）。所以这确实无法扩展以支持多租户解决方案。

现在另一个关键点是，您共享的代码中提到的“密钥”是WA存储帐户密钥。其中只有 2 个，它们是由系统为您生成的。切勿与不需要整个存储帐户的完全管理权限的任何人共享这些内容。您真正与客户共享的是我们之前讨论过的签名。

综上所述，在不了解有关您的场景要求的更多详细信息的情况下，我建议您探索使用外观或看门人风格的模式。通过外观，您可以建立一个服务来验证/授权请求，然后从存储中检索请求的内容。这种方法允许您在调用中引入缓存等概念，以及为更复杂的请求类型聚合结果。在这种情况下，网守模式也相当简单，生成更短时间的共享访问签名（小时/天而不是几周/几个月）。用户将提供某种类型的凭据，然后您可以将其与数据库进行比较，以确定他们是否获得共享访问签名。

我希望这有帮助。 :)