In the Microsoft documentation, it is recommended that professionals use User Delegation Shared Access Signatures rather than key-based Shared Access Signatures. Specifically, why is this the case?
In this document, it is specified that:
Microsoft recommends that you use Azure AD credentials when possible
as a security best practice, rather than using the account key, which
can be more easily compromised. When your application design requires
shared access signatures for access to Blob storage, use Azure AD
credentials to create a user delegation SAS when possible for superior
security.
This Azure official document explains why it is recommended to use User Delegation Shared Access Signatures.
When a client accesses a blob service resource with a user delegation SAS, the request to Azure Storage is authorized with the Azure AD credentials that were used to create the SAS. The role-based access control (RBAC) permissions granted for that Azure AD account, together with the permissions explicitly granted on the SAS, determine the client's access to the resource. This approach provides an additional level of security and avoids the need to store your account access key with your application code. For these reasons, creating a SAS using Azure AD credentials is a security best practice.
Related
In order to connect to Azure Shared Storage(in particularly File Share) to perform tasks like copying/removing/modifying files from remote to azure storage, we need either SAS(Shared Access Signature) or Active Directory Settings Enabled (and then assign roles based on requirement).
I wanted to implement the access using SAS approach, I tried generating SAS from UI, tried generating SAS by making use of Access Keys(Present Inside Storage Account - Confidential and most important key for storage account) both worked. But UI approach isn't conducive in my case, and Access token can't be given to anyone apart from the administrator.
So is there a way to generate SAS using Azure AD credentials or some service where we can create an account and password/key and that account can be used to create SAS token via curl(REST call) and not generating SAS via access keys(admin key).
The tricky part is to let your users create a sas token for the file share without granting them permissions on the whole storage account.
You can use a middle tier application that creates the SAS token and allow the users to use that app. An azure function with an HTTP trigger can be used for example. You grant the azure function access to the storage account using a Managed Service Identity and secure the access to the Azure function either with Active Directory or a function key, that you distribute to your users.
You can try with this approach:
A SAS token for access to a container, directory, or blob may be secured by using either Azure AD credentials or an account key.
Microsoft recommends that you use Azure AD credentials when possible as a security best practice, rather than using the account key, which can be more easily compromised. When your application design requires shared access signatures, use Azure AD credentials to create a user delegation SAS for superior security.
Create a User delegation SAS
Generate a User Delegation Key:
POST https://myaccount.blob.core.windows.net/?restype=service&comp=userdelegationkey
In Microsoft's documentation for user delegation key, it says:
A SAS token for access to a container, directory, or blob may be
secured by using either Azure AD credentials or an account key. A SAS
secured with Azure AD credentials is called a user delegation SAS.
Microsoft recommends that you use Azure AD credentials when possible
as a security best practice, rather than using the account key, which
can be more easily compromised. When your application design requires
shared access signatures, use Azure AD credentials to create a user
delegation SAS for superior security.
Why do this approach give "superior security"? I guess the SAS tokens are both safe? So why exactly is one approach safer than the other? If you use Stored Access Policy, you can also revoke SAS tokens when they have been issues with account keys.
A user-delegation SAS token is more secure that it does not rely on the permissions included in the SAS token only. It also takes into consideration the RBAC permissions of the user who created this SAS token. A SAS token created using shared access key simply considers the permissions included in the SAS token.
For example, let's say the user who's creating a user-delegation SAS only has Read permissions on a blob container (i.e. they can only list or download blobs in a blob container). Now let's say the user creates a SAS token with Write permission. When this SAS token is used to upload a blob, the operation will fail because the user does not have Write permissions on that blob container whereas the upload operation would have succeeded if the SAS token was created using shared access key.
More information on this can be found here (emphasis mine):
When a client accesses a Blob storage resource with a user delegation
SAS, the request to Azure Storage is authorized with the Azure AD
credentials that were used to create the SAS. The role-based access
control (RBAC) permissions granted for that Azure AD account, together
with the permissions explicitly granted on the SAS, determine the
client's access to the resource. This approach provides an additional
level of security and avoids the need to store your account access key
with your application code. For these reasons, creating a SAS using
Azure AD credentials is a security best practice.
The permissions granted to a client who possesses the SAS are the
intersection of the permissions granted to the security principal that
requested the user delegation key and the permissions granted to the
resource on the SAS token using the signedPermissions (sp) field. If a
permission granted to the security principal via RBAC is not also
granted on the SAS token, then that permission is not granted to the
client who attempts to use the SAS to access the resource. When
creating a user delegation SAS, make sure that the permissions granted
via RBAC and the permissions granted via the SAS token both align to
the level of access required by the client.
I'm trying to use Azure RBAC to secure access to storage blobs, and to use Azure Identity to access those blobs from Apache Spark. I see that recent versions of Hadoop-Azure support abfs, and it supports a few token providers: https://hadoop.apache.org/docs/current/hadoop-azure/abfs.html#Azure_Managed_Identity . For production usage, I can use a service principal with an AD app and the associated client id, secret, and endpoint. Or I can even use Managed Identity.
When developing locally, it would be good to be able to do the same with something like DeviceCodeCredential or InteractiveBrowserCredential, i.e. something that will make the user log in to Azure using a browser, and use the credentials returned to get the access token as pass it to Spark. The reason I'd like this is to have users use their own credentials when accessing data, and not have storage keys / SAS tokens / etc flying about.
Is something like this possible? I could implement a Custom Token Provider that wraps an Azure Identity instance, but was wondering if there were a less nuclear approach.
If you want to use the user credential to auth, the closest way in the supported auth ways is the OAuth 2.0: Username and Password, but essentially it uses the Azure AD ROPC flow to auth, it has some limits, e.g. it will not work with the user account which is MFA-enabled.
Actually, for local development, the way I most want to recommend is to use a service principal to auth i.e. OAuth 2.0 Client Credentials, because the MSI(managed identity) is essentially a service principal managed by azure, if you use MSI for production, the transition of the environment will be smoother, the permissions stuff in azure will be some differences between the user account and service principal in some scenarios(maybe not in this case). Of course, Custom Token Provider is also a feasible way, they all depend on yourself.
We are using MS Azure and developing SAAS based Multi-Tenant Application.
For each Tenant we have BLOB Container Private and assigned to each Tenant.
Also there is a requirement that Client can share files with other client users.
Eg.
Client C1 has Container "C1" and it has files "C1f1", "C1f2" and "C1f3".
User U1 and U2. U1 has access permission for C1f1 and U2 has C1f2 access only.
How can we do this in MS Azure Permission or Security? This needs to be done RUNTtime?
Please suggest How can this be done - What is BEST way to do
I believe you have two options.
Either generate and use SAS tokens per client/user with the right permissions. With a SAS token you can provide access to a specific resource up to a specific point in time. The disadvantage is that SAS tokens cannot be revoked on a per token basis. You can only revoke all tokens by rolling the storage access key that was used to generate the SAS token. Another disadvantage is that you have to provide a SAS token per item you want to grant access to. (For more info see also https://azure.microsoft.com/nl-nl/documentation/articles/storage-dotnet-shared-access-signature-part-1/)
Create a Web Service that encapsulates the Azure storage and serves files to your customers. In this service implement authorization management yourself.
I am looking for a feature in Azure similar to AWS Security Token Service (STS) Temporary Security Credentials to allow federated users access Azure services. We are having support for multiple Identity Providers in our application(Amazon account, Microsoft Account, LinkedIn, Google, Facebook, Github & Twitter). We plan to add support for more Identity Providers in the future.
Once the user logs in using one of these Identity Providers, we want to allow access to various Azure services on behalf of these users. AWS has an option to provide temporary access token on behalf of federated users residing in an external Identity Provider(IDP).
Does Azure AD has any similar feature where it generates a token based on an existing token(from external IDP) and allows access to Azure Services?
Thanks
Gaurav
I'm not sure if it exactly meets your needs, but have a look at Azure Role-based Access Control.