...

Find a preliminary comparison of authentication methods:

• From the above comparison Shared Access Signatures are superior concerning more fine-grained access to resources.
• At the same time Shared Key authentication suggests ease of use as a single Shared Key can be used to authenticate any file transfer operations for an unlimited duration.
• Technically a single Shared Access Signature can be applied in a similar way allowing any file transfer operation on any blobs in a given container for a longer period, e.g. the next 100 years.

...

Implementation

User Tasks: Manage Shared Keys and Shared Access Signatures

...

Creating Shared Keys and Shared Access Signatures

• Find examples for creating Shared Keys and SAS tokens on the fly and for using Azure authentication methods and respective file transfer operations from the following articles:
  • Feature Proposal - Azure Blob Storage - Shared Key Authentication
  • Feature Proposal - Azure Blob Storage - Shared Access Signatures
• The samples examples are far from being perfect, however, they might be useful as a basis for a user's implementation.

...

• When using a single Shared Key or Shared Access Signature for all YADE file transfer jobs then
  • this could be added as a constant value to the JobScheduler configuration, e.g. with a parameter to the ./config/scheduler.xml file.
  • this could be added to a Credential Store that would be accessed by any YADE file transfer jobs.
• When using individual Shared Keys or Shared Access Signatures per YADE file transfer job then a Monitor should be implemented that is assigned on a per job basis and that can be parameterized to use the key or signature specified by a job parameter or order parameter.
• Should Shared Keys or Shared Access Signatures have to be renewed on a regular basis then this can be executed performed by a job, e.g. running daily, that is implemented by a user of JobScheduler.

...

• Accept for both Shared Keys and Shared Access Signatures the respective configuration items:
  • Both For both authentication methods
    • Add to URL
      • Resources
      • container resource
      • blob resource
      • Example
        • https://<owner account specified by user>.blob.core.windows.net/<container specified by user>/<blob specified by user>
        • https://yade.blob.core.windows.net/yade/test.txt
    • Add HTTPS headers:
      • x-ms-blob-type : BlockBlob
      • x-ms-date : <date of request>
      • x-ms-version : <version as specified by user>
  • Shared Key
    • Add HTTPS authorization header:
      • Authorization : SharedKey <requester account specified by user>:<signature specified by user>`
  • Shared Access Signatures
    • Add query parameters to URL for list operationoperation to list blobs in a container
      • https://<owner account specified by user>.blob.core.windows.net/<container specified by user>/<blob specified by user>?<query parameters>
      • https://yade.blob.core.windows.net/yade/test.txt?restype=container&comp=list
    • Add SAS token to URL:
      • https://<blob storage owner account specified by user>.blob.core.windows.net/<container specified by user>/<blob specified by user>?<SAS token specified by user>
• Adjust the YADE XSD Schema to allow configuration of any number of HTTP headers
  • at a global level 
  • per profile
  • on a per job basis by job/order parameters and when using the YADE standalone client by command line parameters.
•  Delimitation
  • The implementation is about integrating the above configuration items into HTTPS headers and query parameters.
  • The implementation is not about developing a new data provider that is subject to a separate feature request.

...