Reputation: 894
Azure App Service includes a turnkey authentication solution, under the Authentication/Authorization settings blade. This allowed me to configure Active Directory authentication for my App Service web api. I have a provisioning script for setting up my environment and I would like to automate the configuration of App Service Authentication, either through an ARM template or through Powershell commands.
I've tried using resource.azure.com to view the setup of my site but I couldn't see AD-related config. I've tried searching for ARM templates that do this, without success. I also couldn't see an Azure Resource Manager commandlet that could do this.
Does anyone know how to automate the configuration of App Service Authentication, specifically for AD authentication?
Upvotes: 15
Views: 4654
Reputation: 2974
Edit 2020/06: I found getting a basic example of this working to be unreasonably arcane. Here is a detailed way to get a WebApp to use Azure AD for authentication
Ref: az ad app create
/ az ad app permission
/ az webapp auth update
RSGROUP="MyResourceGroup"
webappname="MyWebSite"
WebAppFDQN=$(az webapp show --name "$webappname" -g "$RSGROUP" --query "defaultHostName" --out tsv);
prodURL="https://myapp.customdomainblah.com";
AADsuffix="/.auth/login/aad/callback" # AD Online is hardcoded to redirect to this path!!
urls="https://${WebAppFDQN}${AADsuffix} ${prodURL}${AADsuffix}";
AADappName="$webappname"
az ad app create \
--display-name "$AADappName" \
--homepage="https://${WebAppFDQN}" \
--reply-urls $urls \
--oauth2-allow-implicit-flow true
Microsoft Graph API w/ Read permission appears to be required.
AADappId=$(az ad app list --display-name "$AADappName" --query [].appId -o tsv);
MSGraphAPI="00000003-0000-0000-c000-000000000000" #UID of Microsoft Graph
Permission="e1fe6dd8-ba31-4d61-89e7-88639da4683d=Scope" # ID: Read permission, Type: Scope
az ad app permission add \
--id "$AADappId" \
--api "$MSGraphAPI" --api-permissions "$Permission"
# Appears to be safe to ignore resulting warning:
# "Invoking "az ad app permission grant --id $AADappId --api $MSGraphAPI" is needed to make the change effective"
Appears idempotent (safe to execute during every deploy)
az webapp auth update \
-g "$RSGROUP" -n "$webappname" --enabled true \
--action LoginWithAzureActiveDirectory \
--aad-client-id "$AADappId"
Previous answer:
This is now merged into Azure CLI and is available under az webapp auth
.
{EDIT: Snipped documentation that was mostly useless - can be seen here: az webapp auth
}
Upvotes: 5
Reputation: 147
Here is a way to do it using straight Powershell commands.
First, you can view the current auth settings using:
$rgName = "ResourceGroupName"
$resourceType = "Microsoft.Web/sites/config"
$resourceName = "service-name/authsettings"
$resource = Invoke-AzureRmResourceAction -ResourceGroupName $rgName `
-ResourceType $resourceType -ResourceName $resourcename -Action list `
-ApiVersion 2015-08-01 -Force
$resource.Properties
Then, you can take the values of those properties and use them to set the PropertyObject (properties shown below relate to AAD authentication, using a service principal):
$PropertiesObject = @{
"enabled" = "True";
"unauthenticatedClientAction" = "0";
"defaultProvider" = "0";
"tokenStoreEnabled" = "True";
"clientId" = "<your client ID here>";
"issuer" = "https://sts.windows.net/<your AAD ID here>/";
"allowedAudiences" = "{https://<service name>.azurewebsites.net}";
"isAadAutoProvisioned" = "True";
"aadClientId" = "<your client ID here>";
"openIdIssuer" = "https://sts.windows.net/<your AAD ID here>/";
}
New-AzureRmResource -PropertyObject $PropertiesObject `
-ResourceGroupName $rgName -ResourceType $resourceType `
-ResourceName $resourcename -ApiVersion 2015-08-01 -Force
I found it easier to enable the authentication in the portal, view the properties, then use those values to set the PropertyObject.
Upvotes: 5
Reputation: 894
I can answer this myself: this can indeed be scripted through an ARM template. (I'd originally tried using resources.azure.com
but it had not shown all of the config info for my site; logging out and back in again made it behave.) The solution is to use a nested resource within the Microsoft.Web/sites
resource for your web app of type config
and name web
to specify the settings, e.g.:
{
"type": "Microsoft.Web/sites",
...
"resources": [
{
"apiVersion": "2015-04-01",
"name": "web",
"type": "config",
"dependsOn": [
"[resourceId('Microsoft.Web/sites', parameters('someName'))]"
],
"properties": {
"siteAuthEnabled": true,
"siteAuthSettings": {
"enabled": null,
"httpApiPrefixPath": null,
"unauthenticatedClientAction": null,
"tokenStoreEnabled": null,
"allowedExternalRedirectUrls": null,
"defaultProvider": null,
"clientId": "REMOVED",
"clientSecret": null,
"issuer": "https://sts.windows.net/REMOVED/",
"allowedAudiences": null,
"additionalLoginParams": null,
"isAadAutoProvisioned": false,
"aadClientId": "REMOVED",
"openIdIssuer": "https://sts.windows.net/REMOVED/",
"googleClientId": null,
"googleClientSecret": null,
"googleOAuthScopes": null,
"facebookAppId": null,
"facebookAppSecret": null,
"facebookOAuthScopes": null,
"twitterConsumerKey": null,
"twitterConsumerSecret": null,
"microsoftAccountClientId": null,
"microsoftAccountClientSecret": null,
"microsoftAccountOAuthScopes": null
}
}
}
]
}
Upvotes: 14