It’s possible to authenticate to a storage account using an OAuth token obtained via Azure Active Directory (AAD). This has several advantages:
Here, we’ll take you through the steps involved to configure a storage account for AAD authentication. The assumption here is that you’re an administrator for your AAD tenant, or have the appropriate rights to create AAD app registrations and set role assignments on resources—if you don’t know what these terms mean, you probably don’t have such rights!
Authenticating as a user is relatively straightforward: you can think of it as “logging into” the storage account with your username. This involves the following:
You can create a new app registration using any of the usual methods. For example to create an app registration in the Azure Portal (https://portal.azure.com/), click on “Azure Active Directory” in the menu bar down the left, go to “App registrations” and click on “New registration”. Name the app something suitable, eg “AzureStor R interface to storage”.
http://localhost:1410. This is appropriate if your users will be running R on their local PCs, with an Internet browser available.Once the app registration has been created, note the app ID.
To enable users to authenticate to storage with this app, add the “user_impersonation” delegated permission for the Azure Storage API. In the Portal, you can set this by going to the “API permissions” pane for your app reigstration, then clicking on “Add a permission”.
Having registered an app ID for AzureStor, you then add the appropriate role assignments for your users. These role assignments are set for the resource, not the app registration. In the Portal, you can set these by going to your storage account resource, then clicking on “Access Control (IAM)”.
The main role assignments to be aware of are:
Note that AzureStor does not provide an R interface to queue storage; for that, you can use the AzureQstor package.
Once this is done, your users can authenticate to storage as follows. Here. app_id is the ID of the app registration you’ve just created.
# obtaining a token from an R session on the local machine
token <- AzureAuth::get_azure_token("https://storage.azure.com", tenant="yourtenant", app="app_id")
# obtaining a token from a remote R session: RStudio Server/Databricks
token <- AzureAuth::get_azure_token("https://storage.azure.com", tenant="yourtenant", app="app_id",
auth_type="device_code")
# use the token to login to storage (blob in this case)
endp <- storage_endpoint("https://yourstorageacct.blob.core.windows.net", token=token)In the previous section, we described how users can authenticate as themselves with AzureStor. Here, we’ll describe how to authenticate as the application, that is, without a signed-in user. This is useful in a scenario such as a CI/CD or deployment pipeline that needs to run without user intervention.
The process is as follows:
Creating the app registration is much the same as before, except that you don’t need to set a redirect URI or enable public client flows. Instead you give the app a client secret, which is much the same as a password (and should similarly be kept secure). In the Portal, you can set this in the “Certificates and Secrets” pane for your app registration.
It’s also possible to authenticate with a client certificate (public key), but this is more complex and we won’t go into it here. For more details, see the Azure Active Directory documentation and the AzureAuth intro vignette.
This is again similar to assigning a user a role, except now you assign it to the service principal for your app. The same roles assignments as before can be used.
To authenticate as the app, use the following code: