[ 
https://issues.apache.org/jira/browse/JCLOUDS-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16683273#comment-16683273
 ] 

Himanshu Jain commented on JCLOUDS-1428:
----------------------------------------

Hi [~gaul]

Sorry for this late response. 
Thanks for your suggestion. I figured using BlobRequestSigner we can send 
signed request to upload/download objects. But the signed HttpRequest is 
generated as part of the implementation. We have no control over the SAS token. 
In our case, we already have a SAS token which we provide to our client to 
provide limited access to objects in our storage accounts. 
Specifically, allowing only object related permissions inside a container 
within a storage account. 

Is there a way through which we can configure the BlobStoreContext or 
BlobRequestSigner by passing the SAS token that we have, 
So, that a user can only have access over objects within a container and not on 
the containers within a storage account.


Thanks and Regards,
Himanshu

> 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
>
> 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)

Reply via email to