[
https://issues.apache.org/jira/browse/JCLOUDS-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16791408#comment-16791408
]
Swati Jain commented on JCLOUDS-1428:
-------------------------------------
Hi [~Horuszko]
Based on the discussion above and the understanding that we have so far, these
4 different keys are assumed to be mandatory "sig", "se", "sv", "sp" for a SAS
token in current implementation of JClouds.
We would want to let you know the following, (may be you already know about it)
:
* There are 2 types of SAS tokens - 1) Service SAS and 2) Account SAS. We make
use of *Service SAS*.
[Reference|[https://docs.microsoft.com/en-us/azure/storage/common/storage-dotnet-shared-access-signature-part-1#types-of-shared-access-signatures]]
* There are 2 forms of SAS tokens - 1) Ad hoc SAS and 2) SAS with stored
access policy. We make use of *SAS with stored access policy.*
[Reference|[https://docs.microsoft.com/en-us/azure/storage/common/storage-dotnet-shared-access-signature-part-1#controlling-a-sas-with-a-stored-access-policy]]
Please note that a SAS created using stored access policy inherits expiry time
and permissions from the policy itself. Azure documentation states the
following :
{quote}When you associate a SAS with a stored access policy, the SAS inherits
the constraints the start time, expiry time, and permissions, defined for the
stored access policy.
{quote}
As we make use of *Service SAS with stored access policy*, the "se" and "sp"
parameters aren't part of such a SAS token. Still such a token is valid and we
are able to make all the allowed operations on the given resource.
Also, please note that such a token is generated using the Azure SDK. Following
are some code snippets :
// Specifying permissions
{quote}{{EnumSet<SharedAccessBlobPermissions> permissions =
EnumSet.of(SharedAccessBlobPermissions.READ,}}
{{SharedAccessBlobPermissions.ADD, SharedAccessBlobPermissions.CREATE,
SharedAccessBlobPermissions.WRITE,}}
{{SharedAccessBlobPermissions.DELETE, SharedAccessBlobPermissions.LIST);}}
{quote}
// Creating policy
{quote}{{SharedAccessBlobPolicy sharedAccessBlobPolicy = new
SharedAccessBlobPolicy();}}
{quote}
// Assigning expiry time and permissions to the policy
{quote}{{sharedAccessBlobPolicy.setPermissions(permissions);}}
{{sharedAccessBlobPolicy.setSharedAccessStartTime(startTime);}}
{{sharedAccessBlobPolicy.setSharedAccessExpiryTime(endTime); }}
{quote}
// Generating SAS token using the above policy
[Reference|[https://azure.github.io/azure-sdk-for-java/com/microsoft/azure/storage/blob/CloudBlobContainer.html#generateSharedAccessSignature-com.microsoft.azure.storage.blob.SharedAccessBlobPolicy-java.lang.String-com.microsoft.azure.storage.IPRange-com.microsoft.azure.storage.SharedAccessProtocols-]]
{quote}{{String sasToken =
cloudBlobContainer.generateSharedAccessSignature(null, policyIdentifier, null,
SharedAccessProtocols.HTTPS_ONLY);}}
{quote}
Using the above method, the SAS token generated doesn't contain "se" and "sp"
parameters. Rather it contains "si" parameter, that refers to signed identifier.
Therefore, the SAS token that we make use of is a valid one we believe.
Please let us know if the above explanation clarifies that the SAS token that
we generate and make use of is correct. If not, we can also have a short call
to discuss upon the same.
> Support for SAS token based Authentication for Azure Blob Storage
> -----------------------------------------------------------------
>
> Key: JCLOUDS-1428
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1428
> Project: jclouds
> Issue Type: Improvement
> Components: jclouds-blobstore
> Reporter: Himanshu Jain
> Priority: Major
> Labels: azureblob
> Fix For: 2.2.0, 2.1.3
>
> Attachments: azure_stacktrace.txt
>
>
> Hi,
> We have one use case where we want to provide limited access to objects in
> our storage accounts. We figured that the best way to do this is by using
> SAS token based authentication mechanism to upload/download objects to Azure
> Blob Storage - [SAS based
> Authentication|https://docs.microsoft.com/en-us/azure/storage/common/storage-dotnet-shared-access-signature-part-1]
> We found that JClouds client library provides support for Azure Blob Storage
> using account keys which might not fit our use case because of security
> reasons.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)