jclouds-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Swati Jain (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (JCLOUDS-1428) Support for SAS token based Authentication for Azure Blob Storage
Date Wed, 13 Mar 2019 07:50:00 GMT

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

Swati Jain edited comment on JCLOUDS-1428 at 3/13/19 7:49 AM:
--------------------------------------------------------------

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
{code:java}
EnumSet<SharedAccessBlobPermissions> permissions = EnumSet.of(SharedAccessBlobPermissions.READ,
 SharedAccessBlobPermissions.ADD, SharedAccessBlobPermissions.CREATE, SharedAccessBlobPermissions.WRITE,
 SharedAccessBlobPermissions.DELETE, SharedAccessBlobPermissions.LIST);{code}
// Creating policy
{code:java}
SharedAccessBlobPolicy sharedAccessBlobPolicy = new SharedAccessBlobPolicy();{code}
// Assigning expiry time and permissions to the policy

 
{code:java}
sharedAccessBlobPolicy.setPermissions(permissions);
sharedAccessBlobPolicy.setSharedAccessStartTime(startTime);
sharedAccessBlobPolicy.setSharedAccessExpiryTime(endTime);
{code}
// 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-]]
{code:java}
String sasToken = cloudBlobContainer.generateSharedAccessSignature(null, policyIdentifier,
null, SharedAccessProtocols.HTTPS_ONLY);{code}
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. 


was (Author: swatijain1101):
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)

Mime
View raw message