Azure Functions und Azure AD-Authentifizierung
Dieser Beitrag ist Teil einer Reihe über Azure Functions und PowerShell. Schauen Sie sich die Liste der anderen Beiträge der Serie an!
Azure Functions und Azure AD-Authentifizierung
Azure Functions sind einfach, günstig und skalierbar.
PowerShell ist eine leistungsstarke Sprache, die sich perfekt für die Automatisierung und Erstellung von Integrationen eignet, die Systeme „zusammenkleben“.
Das ist für mich eine himmlische Übereinstimmung, aber woher weiß und validiere ich, wer meinen Code aufruft? Hier kommt die Authentifizierung ins Spiel. Bei der Authentifizierung geht es darum, zu überprüfen, wer eine Verbindung zu meiner Anwendung herstellt, damit ich (oder mein Code) bestimmen kann, ob er dazu berechtigt sein soll oder nicht.
Fordern Sie den Azure AD-Benutzer auf, sich bei Azure Functions anzumelden
Fangen wir einfach an. Ich möchte, dass Benutzer sich bei AzureAD authentifizieren, wenn sie meine Funktion aufrufen.
Dieses Szenario ist eigentlich sehr einfach, da es sich um eine in Azure Functions enthaltene Funktion handelt, oder um fair zu sein, sie ist in Azure App Service enthalten, auf dem Functions aufbaut. Diese Funktion kann in einem der beiden Verwaltungsmodi Express oder Advanced aktiviert werden. Und da ich gerne wirklich verstehen möchte, wie die Dinge funktionieren, werde ich beides behandeln.
Die Funktion, die wir hierfür verwenden, hieß früher easyauth. Wenn Sie nach Azure App Service und easyauth oder „easy auth“ suchen, erhalten Sie möglicherweise wertvolle Informationen.
Zur Authentifizierung können Sie zwischen dem Express- und dem erweiterten Modus wählen
Wie in den meisten anderen Fällen gibt es einen einfachen und einen weniger einfachen Weg, Dinge zu erledigen. In diesem Fall wird der einfache Weg als Express-Modus bezeichnet. Um die Mouseover-Erklärung zu zitieren:
„Der Express-Modus verwendet Ihr Standard-AAD und kann eine AAD-Anwendung für Sie erstellen.“ Wählen Sie den erweiterten Modus, wenn Sie eine benutzerdefinierte AAD-Konfiguration wünschen.“
Der Express-Modus lässt sich in Sekundenschnelle einrichten und funktioniert für die meisten einfachen Szenarien, aber man kann ihn nur einmal einrichten und ich komme oft in die Situation, dass ich später Dinge ändern möchte, was im Express-Modus etwas schwieriger ist.
Es gibt noch einen weiteren Nachteil des Express-Modus, den Sie beachten müssen. Zum Zeitpunkt der Erstellung dieses Artikels im Oktober 2020 richtete der Expressmodus eine Azure AD V1-Anwendung ein. Wenn wir den neueren V2-Endpunkt verwenden möchten, müssen wir den erweiterten Modus verwenden. Microsoft empfiehlt die Verwendung des V2-Endpunkts für neue Projekte. Weitere Informationen finden Sie unter Warum auf Microsoft Identity Platform (v2.0) aktualisieren.
Active Directory-Authentifizierung Express-Modus
In diesem Szenario gehe ich davon aus, dass wir über eine funktionierende Funktions-App verfügen und dass der Benutzer, der diese Schritte ausführt, Anwendungen in Azure Active Directory registrieren darf.
Gehen Sie zunächst zum Blatt „Authentifizierung/Autorisierung“.
Wie uns der Warntext sagt, müssen wir unsere SSL-Konfiguration in Ordnung haben, die .NET-Version 4.5 oder höher verwenden und den Verwaltungs-Pipeline-Modus auf „integriert“ einstellen. Da dies die Standardeinstellungen für eine neue Funktions-App sind, werde ich hier nicht näher darauf eingehen.
Aktivieren Sie die App Service-Authentifizierung und stellen Sie das Dropdown-Menü „Auszuführende Aktion, wenn die Anforderung nicht authentifiziert wird“ auf „Mit Azure Active Directory anmelden“ ein. Dadurch wird jede nicht authentifizierte Anfrage an eine Anmeldeaufforderung weitergeleitet.
Klicken Sie unter Authentifizierungsanbieter auf Azure Active Directory.
Ändern Sie in den Azure Active Directory-Einstellungen den Verwaltungsmodus von „Aus“ in „Express“, wählen Sie einen guten Namen für Ihre neue App (er muss in Ihrem Mandanten eindeutig sein), lassen Sie den Rest unverändert und klicken Sie auf „OK“.
Wenn Sie wieder im Authentifizierungs-/Autorisierungsblatt sind, vergessen Sie nicht, auf die Schaltfläche „Speichern“ zu klicken.
Und so einfach ist das! Wir haben jetzt eine Funktion, die eine Azure AD-Authentifizierung erfordert! Probieren wir es aus!
Rufen Sie die URL zu einer Funktion ab, indem Sie zu „Funktionen“ gehen, eine Funktion auswählen, in meinem Fall „HttpTrigger1“, und oben auf dem Blatt auf „Funktions-URL abrufen“ klicken.
Geben Sie die vollständige Funktions-URL in einen Webbrowser ein und Sie werden zu einer Anmeldeaufforderung weitergeleitet. Wenn Sie sich zum ersten Mal bei dieser Anwendung anmelden, wird Ihnen eine Einwilligungsanfrage angezeigt.
Wenn Sie ein Anwendungsadministrator im Mandanten sind, sehen Sie außerdem ein Kontrollkästchen mit der Aufschrift „Zustimmung im Namen Ihrer Organisation“. Wenn Sie einfach auf „Akzeptieren“ klicken, wird nur der aktuelle Benutzer akzeptiert. Durch Aktivieren des Kontrollkästchens und anschließendes Klicken auf „Akzeptieren“ wird die App-Zustimmung für jeden Benutzer im Mandanten erteilt, die sogenannte Administrator-Zustimmung.
Um diese Frage überhaupt nicht zu erhalten, könnten wir die Zustimmung des Administrators erteilen, bevor wir versuchen, uns anzumelden. Dies kann im Azure-Portal erfolgen, indem wir zu Azure Active Directory und dem Blatt „App-Registrierungen“ navigieren. Wählen Sie die Registerkarte „Alle Anwendungen“, suchen Sie die gerade erstellte App und gehen Sie im linken Menü auf „API-Berechtigungen“. Auf dem neuen Blatt, das geöffnet wird, können wir sehen, dass die Anwendung die delegierte Berechtigung „User.Read“ für die Graph-API benötigt. Um dies für alle Benutzer in Ihrer Organisation zu genehmigen, klicken Sie einfach auf „Administratoreinwilligung für
Und das ist es!
Erweiterter Modus der Active Directory-Authentifizierung
Wenn eine der folgenden Aussagen zutrifft, möchten Sie wahrscheinlich die erweiterten Einstellungen für die Autorisierung verwenden.
- Ich möchte die neue Microsoft Identity Platform nutzen
- Ich möchte eine App verwenden, die in einem anderen Azure AD-Mandanten registriert ist
- Ich möchte eine bessere Kontrolle und ein besseres Verständnis dessen, was ich einrichte
- Ich kann selbst keine Anwendungen erstellen und muss jemanden bitten, sie für mich zu erstellen
Um die Autorisierung mit erweiterten Einstellungen einzurichten, müssen wir zunächst eine App-Registrierung für unsere API erstellen.
Da ich kein Fan davon bin, in Portalen zu klicken, mache ich das gerne mit einer Art Skript. Dieses Mal werde ich Azure CLI von PowerShell verwenden. Aktualisieren Sie den Anzeigenamen und die Bezeichner-URI entsprechend Ihrem Szenario und führen Sie das Skript aus.
Dieses Skript erledigt einige Dinge. Zuerst konfiguriere ich einen Anzeigenamen für meine Anwendung und den Namen meiner Funktions-App.
Dann sammle ich einige Zugriffsberechtigungen, die meine App benötigt, um Informationen über den angemeldeten Benutzer zu erhalten. Ich mache das, damit ich all diesen Berechtigungen in meinem Skript zustimmen kann und diesen Zustimmungsdialog nie sehen muss.
Sobald wir alle diese Informationen haben, erstellen wir die Anwendung mit az ad app create und einen Dienstprinzipal mit az ad sp create.
Dann erteilen wir allen Benutzern die Berechtigungen E-Mail, OpenID und Profil. Dies ist der Zustimmungsteil.
Zuletzt setzen wir requestedAccessTokenVersion auf den Wert 2. Dadurch wird der Wert accessTokenAcceptedVersion in unserem Manifest auf 2 gesetzt und Azure AD mitgeteilt, dass wir V2-Endpunkt-Tokens benötigen. Jetzt verwendet Azure CLI derzeit die Azure AD Graph-API, die dies nicht unterstützt. Daher verwende ich az rest, um Microsoft Graph für diesen Schritt aufzurufen.
$ServerAppDisplayName = 'MySuperAPI'
$SystemName = 'mycoolfunction'
# Get tenant id of current tenant
# (make sure to be signed in with az cli)
$TenantId = az account show --query 'tenantId' -o tsv
# Server app identifier, needs to be unique
# I'll default to an azure websites url
# Update to something that fits you
$ServerAppIdentifierUri = "https://$SystemName.azurewebsites.net"
# ReplyUris, this is where AzureAD will send the token.
# Make sure to get this right!
$ReplyUri = "https://$SystemName.azurewebsites.net/.auth/login/aad/callback"
# Create configuration for delegated permissions to graph API
# Get application id of Microsoft Graph
$GraphAppId = az ad sp list --query '[?appDisplayName==''Microsoft Graph''].appId' -o tsv --all
# Get all permissions available to graph
$Permissions = az ad sp show --id $GraphAppId --query 'oauth2Permissions' | ConvertFrom-Json
# Select the permissions we need
$EmailPermission = $Permissions.Where{ $_.value -eq 'email' }.id
$ProfilePermission = $Permissions.Where{ $_.value -eq 'profile' }.id
$OpenIdPermission = $Permissions.Where{ $_.value -eq 'openid' }.id
# Build part of a manifest for requiredResourceAccess
$requiredResourceAccess = @(
@{
resourceAppId = $GraphAppId
resourceAccess = @(
@{
id = $EmailPermission
type = 'Scope'
},
@{
id = $ProfilePermission
type = 'Scope'
},
@{
id = $OpenIdPermission
type = 'Scope'
}
)
}
) | ConvertTo-Json -AsArray -Depth 4 -Compress | ConvertTo-Json
# Pipe to ConvertTo-Json twice to escape all quotes, or az cli will remove them when parsing
# Register the application
$ServerApp = az ad app create --display-name $ServerAppDisplayName --identifier-uris $ServerAppIdentifierUri --required-resource-accesses $requiredResourceAccess --reply-urls $ReplyUri | ConvertFrom-Json
# Create a service principal for the application
$null = az ad sp create --id $ServerApp.AppId
# Consent the application for all users
$null = az ad app permission grant --id $ServerApp.AppId --api $GraphAppId --scope "email openid profile"
# Set application to use V2 access tokens
$Body = @{
api = @{
requestedAccessTokenVersion = 2
}
} | ConvertTo-Json -Compress | ConvertTo-Json
# Pipe to ConvertTo-Json twice to escape all quotes, or az cli will remove them when parsing
$null = az rest --method PATCH --uri "https://graph.microsoft.com/v1.0/applications/$($ServerApp.objectId)" --body $Body --headers "Content-Type=application/json"
# Output the ClientId for use later
Write-Output $ServerApp.AppId
In meinem Fall habe ich die AppId von c491d3f8-0d15-4ea5-96fd-957601d579fa erhalten. Dies wird auch als clientId für meine App bezeichnet. Wir werden das später brauchen, also schreiben Sie es unbedingt auf.
Gehen wir zu unserer Funktions-App im Azure-Portal. Navigieren Sie zum Blatt „Authentifizierung/Autorisierung“, wählen Sie „Ein“, verwenden Sie die Aktion „Mit Azure Active Directory anmelden“ und klicken Sie auf „Azure Active Directory“, genau wie wir es mit dem Express-Modus getan haben.
Dieses Mal wählen wir „Erweitert“ statt „Express“. Hier müssen wir die ClientId (AppId) aus unserer Registrierung oben sowie eine Issuer-URL eingeben. Die Aussteller-URL besteht aus den folgenden Teilen: „az account show ausführen oder den PowerShell-Befehl Get-AzContext verwenden.
Und jetzt sollten wir in der Lage sein, zu unserer Funktion zu navigieren, zu einer Anmeldeseite weitergeleitet zu werden und dann zu unserer Funktion zu gelangen. So einfach ist das!
Schlussfolgerungen zur Authentifizierung
Zusammenfassend lässt sich sagen: Wenn Sie bereit sind, ein paar Minuten statt ein paar Sekunden in die Konfiguration der Authentifizierung zu investieren, kann sich die Entscheidung für den sogenannten erweiterten Weg durchaus lohnen!
Wie wir oben gesehen haben, benötigen wir zum Erhalt eines Zugriffstokens eine in Azure AD registrierte Anwendung. Die bisher von uns erstellten Anwendungen sind als Webserver-Anwendungen konzipiert. Das bedeutet, dass der Tokenaussteller (in unserem Fall Azure AD) das Zugriffstoken nicht an den Client zurückgibt, wenn sich ein Benutzer anmeldet, sondern dass Azure AD es an den vom Client angegebenen Umleitungs-URI sendet. Azure AD akzeptiert nur Umleitungs-URIs, die in unserer Anwendungsregistrierung aufgeführt sind. Das bedeutet, dass es EXTREM wichtig ist, die richtigen RedirectURIs hinzuzufügen und nur diese.
Im obigen erweiterten Szenario legen wir diesen Umleitungs-URI auf den URI unserer Funktion fest, gefolgt von „/.auth/login/aad/callback“.