Support for GetSASURL for signing BLOB URLs using User Delegation Credentials

[pfreixes]

Feature Request

Today the GetSASURL does only support signing Blob URLs when the client was instantiated by using shared account keys, while its still allowable to generate SAS URLs with user delegation credentials - indeed the usage of user delegation credentials are promoted as most secured option - using the SignWithUserDelegation.SignWithUserDelegation API interface the GetSASURL does not allow any usage of it.

This prevents users to have an orthogonal API which works seamless with one or another authentication method, where ideally the GetSASURL could be agnostic to how the client was instantiated, and supporting both ways for generating SAS URLs.

Side effects of using user delegation credentials for getting SAS URLs

From my understanding, one of the down side-effects of using SAS URLs is that every call to GetSASURL would need to make an HTTP call for getting a new delegation key. Which could impact in the latency for generating a new SAS URL since a new HTTP call would need to be made, and also it would impact the costs for the since all calls for getting a user delegation key would get billed.

If this was or its a concern for not having GetSASURL supporting also user delegation credentials, this could be - unless Im missing something - addressed by reusing the same delegation key more than once, having it refreshed behind the scenes by the SDK with a key expiration that should be at least longer than the max expiry time of the SAS URLs.

This could be a feature that the user could opt in in case the user would want to address the two concerns expressed, otherwise the default behaviour could be still the usage of 1 single delegation key per each call to the GetSASURL method.

If you believe that this is something that you would up to add in the SDK I would be more than happy to work on a PR.

[pfreixes]

A side question regarding the SAS URLs generated using User Delegation Keys, we have observed that every time that we retrieve a user delegation key, a new key is being returned which is kinda expected.

But when the key is used for generating the SAS URL there is no parameter that identifies univocally the key, while there are others that are pointing to the Identity id (skoid) or the tenant ID (sktid) there seems to be no identifier for the key, which made us think about how are keys retrieved later at Azure side for checking a SAS URL and its signature. I guess that our main question here is, will be any problem if hundreds - if not thousands or millions - of keys are created? will Azure keep managing well this situation?

We understand that this not a big concern when using account shared keys, since there is just one single account shared key, but this questions arises when using user delegation keys.

Thanks!

[tanyasethi-msft]

Hi @pfreixes, to answer your second question,
Each time you request a user delegation key from Azure, a new key is generated. This is expected, as these keys are designed to be temporary and secure. Although the generated SAS URL does not include a direct identifier for the delegation key used, it does include identifiers for the Azure AD identity (skoid for the object ID of the security principal and sktid for the Azure AD tenant ID). These elements are part of the SAS token's signed components, ensuring the SAS can only be used by the entity that generated it and within its validity period.