Azure İşlevleri ve Azure AD kimlik doğrulaması
Bu gönderi, Azure İşlevleri ve PowerShell ile ilgili bir serinin parçasıdır. Serideki diğer gönderilerin listesine göz atın!
Azure İşlevleri ve Azure AD kimlik doğrulaması
Azure İşlevleri kolay, ucuz ve ölçeklenebilirdir.
PowerShell, sistemleri birbirine "yapıştıran" entegrasyonları otomatikleştirmek ve yazmak için mükemmel, güçlü bir dildir.
Bu benim için cennette yapılmış bir eşleşme, ancak kodumu kimin aradığını nasıl bilip doğrulayacağım? Kimlik Doğrulamanın sahneye girdiği yer burasıdır. Kimlik doğrulama tamamen uygulamama kimin bağlandığını doğrulamakla ilgilidir, böylece ben (veya kodum) bu kişilerin bunu yapmaya yetkili olup olmadığına karar verebilirim.
Azure AD kullanıcısının Azure İşlevlerinde oturum açmasını zorunlu kılın
Basit başlayalım. Kullanıcıların işlevimi çağırdıklarında AzureAD ile kimlik doğrulaması yapmalarını istiyorum.
Bu senaryo aslında çok basittir çünkü Azure İşlevlerinde bulunan bir özelliktir veya adil olmak gerekirse, İşlevlerin üzerine inşa edildiği Azure Uygulama Hizmetinde bulunur. Bu özellik, Express veya Advanced olmak üzere iki yönetim modundan birinde etkinleştirilebilir. İşlerin nasıl yürüdüğünü gerçekten anlamayı sevdiğim için her ikisine de değineceğim.
Bunun için kullandığımız özelliğe easyauth adı veriliyordu. Azure App Service ve easyauth veya "kolay kimlik doğrulama"yı aramak size bazı değerli bilgiler sağlayabilir.
Kimlik doğrulama için Ekspres ve Gelişmiş mod arasında seçim yapma
Çoğu durumda olduğu gibi, işleri yapmanın kolay ve daha az kolay bir yolu vardır. Bu durumda kolay yola Ekspres mod denir. Fareyle üzerine gelindiğinde yapılan açıklamayı alıntılamak için:
“Ekspres mod, varsayılan AAD'nizi kullanır ve sizin için bir AAD uygulaması oluşturabilir. Özel bir AAD yapılandırmasına sahip olmak istiyorsanız gelişmiş modu seçin”
Ekspres mod saniyeler içinde kurulabilir ve çoğu basit senaryo için çalışır, ancak bunu yalnızca bir kez ayarlayabilirsiniz ve çoğu zaman bazı şeyleri daha sonra değiştirmek istediğim bir durumla karşı karşıya kalırım ve bu, Ekspres modu kullanırken biraz daha zordur.
Ekspres modun bilmeniz gereken başka bir dezavantajı da vardır. Ekim 2020'de bunu yazarken ekspres mod bir Azure AD V1 uygulaması kuruyor. Daha yeni V2 uç noktasını kullanmak istiyorsak gelişmiş modu kullanmamız gerekir. Microsoft, yeni projeler için V2 uç noktasının kullanılmasını önerir. Daha fazla bilgi için neden Microsoft Identity Platform'a (v2.0) güncellendiğine göz atın.
Active Directory Kimlik Doğrulaması Ekspres modu
Bu senaryoda, çalışan bir İşlev Uygulamamız olduğunu ve bu adımları gerçekleştiren kullanıcının uygulamaları Azure Active Directory'ye kaydetmesine izin verildiğini varsayıyorum.
“Kimlik Doğrulama/Yetkilendirme” dikey penceresine giderek başlayın.
Uyarı metninin bize söylediği gibi, SSL yapılandırmamızı düzenli yapmamız, .NET 4.5 veya üzeri sürümünü kullanmamız ve ardışık düzeni yönetme modunu “entegre” olarak ayarlamamız gerekiyor. Bu, yeni bir İşlev Uygulamasının varsayılan ayarları olduğundan burada bu konuya girmeyeceğim.
App Service Kimlik Doğrulamasını açın, "İstek kimlik doğrulaması yapılmadığında gerçekleştirilecek eylem" açılır menüsünü "Azure Active Directory ile oturum açın" olarak ayarlayın. Bu, kimliği doğrulanmamış tüm istekleri oturum açma istemine yönlendirecektir.
Kimlik Doğrulama Sağlayıcıları altında Azure Active Directory'ye tıklayın.
Azure Active Directory Ayarlarına girdikten sonra, Yönetim Modunu Kapalı'dan Ekspres'e değiştirin, yeni uygulamanız için iyi bir ad seçin (kiracınızda benzersiz olması gerekir), gerisini olduğu gibi bırakın ve Tamam'a tıklayın.
Kimlik doğrulama/yetkilendirme dikey penceresine döndüğünüzde kaydet düğmesine tıklamayı unutmayın.
Ve bu kadar basit! Artık Azure AD Kimlik Doğrulaması gerektiren bir işlevimiz var! Haydi deneyelim!
İşlevler'e giderek bir işlevin URL'sini alın, benim durumumda "HttpTrigger1" gibi bir işlev seçin ve bıçağın üstündeki "İşlev URL'sini Al"ı tıklayın.
Bir web tarayıcısına tam işlev URL'sini girin; oturum açma istemine yönlendirileceksiniz. Bu uygulamada ilk kez oturum açıyorsanız size bir onay talebi sunulacaktır.
Kiracıda uygulama yöneticisiyseniz “Kuruluşunuz adına onay” yazan bir onay kutusu da göreceksiniz. Kabul Et'e tıkladığınızda yalnızca geçerli kullanıcı kabul edilir. Kutunun işaretlenmesi ve ardından kabul et seçeneğinin tıklatılması, kiracıdaki her kullanıcı için uygulamaya yönetici izni adı verilen izni verecektir.
Bu soruyu hiç almamak için, oturum açmayı denemeden önce yönetici onayı verebiliriz. Bu, Azure Portal'da Azure Active Directory ve Uygulama Kayıtları dikey penceresine giderek yapılabilir. “Tüm Uygulamalar” sekmesini seçin, yeni oluşturulan uygulamayı bulun ve sol menüdeki “API İzinleri” ne gidin. Açılan yeni blade'de uygulamanın Graph API'sine User.Read'in yetkilendirilmiş iznini gerektirdiğini görebiliriz. Bunu kuruluşunuzdaki tüm kullanıcılar için onaylamak üzere "
Ve bu kadar!
Active Directory Kimlik Doğrulaması Gelişmiş modu
Aşağıdaki ifadelerden herhangi biri doğruysa, muhtemelen Yetkilendirme için gelişmiş ayarları kullanmak istersiniz.
- Yeni Microsoft Identity platformunu kullanmak istiyorum
- Başka bir Azure AD Kiracısında kayıtlı bir uygulamayı kullanmak istiyorum
- Ne kurduğumu daha iyi kontrol etmek ve anlamak istiyorum
- Kendi başıma uygulama oluşturma erişimim yok ve birinden bunları benim için oluşturmasını istemem gerekiyor
Yetkilendirmeyi gelişmiş ayarlarla ayarlamak için öncelikle API'miz için bir uygulama kaydı oluşturmamız gerekir.
Portallara tıklamayı pek sevmediğim için bunu bir tür senaryoyla yapmayı seviyorum. Bu sefer PowerShell'in Azure CLI'sini kullanacağım. Görünen adı ve tanımlayıcı uri'yi senaryonuza uyacak şekilde güncelleyin ve betiği çalıştırın.
Bu komut dosyası birkaç şey yapar. Öncelikle uygulamam için bir görünen ad ve İşlevler Uygulamamın adını yapılandırıyorum.
Ardından, uygulamamın oturum açmış kullanıcı hakkında bilgi almak için ihtiyaç duyduğu bazı erişim izinlerini topluyorum. Bunu, betiğimdeki tüm bu izinlere izin verebilmek ve bu izin iletişim kutusunu hiçbir zaman görmek zorunda kalmamak için yapıyorum.
Tüm bu bilgilere sahip olduktan sonra az ad app create kullanarak uygulamayı ve az ad sp create kullanarak bir hizmet sorumlusu oluştururuz.
Daha sonra tüm kullanıcılara email, openid ve profile izinlerini veriyoruz, bu izin kısmı.
Son olarak requestedAccessTokenVersion değerini 2 değerine ayarladık. Bu, bildirimimizde accessTokenAcceptedVersion değerini 2 olarak ayarlayacak ve Azure AD'ye V2 uç nokta belirteçleri istediğimizi bildirecektir. Artık Azure CLI şu anda bunu desteklemeyen Azure AD Graph API'sini kullanıyor, bu nedenle bu adım için Microsoft Graph'ı çağırmak üzere az rest kullanıyorum.
$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
Benim durumumda c491d3f8-0d15-4ea5-96fd-957601d579fa Uygulama Kimliğini aldım. Bu aynı zamanda uygulamamın clientID'si olarak da bilinir. Buna daha sonra ihtiyacımız olacak, bu yüzden yazdığınızdan emin olun.
Azure Portal'daki işlev uygulamamıza gidelim. Kimlik Doğrulama/Yetkilendirme dikey penceresine gidin, Açık'ı seçin, “Azure Active Directory ile oturum açın” eylemini kullanın ve tıpkı Ekspres Modda yaptığımız gibi Azure Active Directory'ye tıklayın.
Bu sefer Ekspres yerine Gelişmiş'i seçeceğiz. Burada yukarıdaki kaydımızdan ClientId'yi (AppId) ve Verici URL'sini girmemiz gerekiyor. Veren URL'si şu bölümlerden oluşur: "az account show çalıştırarak veya Get-AzContext PowerShell komutunu kullanarak alabilirsiniz.
Artık fonksiyonumuza göz atabilmemiz, oturum açma sayfasına yönlendirilebilmemiz ve ardından fonksiyonumuza ulaşabilmemiz gerekiyor. Bu kadar basit!
Kimlik doğrulama için sonuçlar
Özetlemek gerekirse, kimlik doğrulamayı yapılandırmak için birkaç saniye yerine birkaç dakika harcamaya hazırsanız, sözde gelişmiş rotaya gitmek, çabaya değer olabilir!
Yukarıda gördüğümüz gibi erişim tokenlarını alabilmek için Azure AD’ye kayıtlı bir uygulamaya ihtiyacımız var. Şu ana kadar oluşturduğumuz uygulamalar web sunucusu uygulaması görevi görecek şekilde tasarlandı. Bu, bir kullanıcı oturum açtığında belirteç verenin (bizim durumumuzda Azure AD) erişim belirtecini istemciye iade etmeyeceği, Azure AD'nin bunu istemci tarafından belirtilen yönlendirme URI'sine göndereceği anlamına gelir. Azure AD yalnızca uygulama kaydımızda listelenen yönlendirme URI'lerini kabul edecektir. Bu, doğru yönlendirme URI'lerini ve yalnızca bunları eklemenin SON DERECE önemli olduğu anlamına gelir.
Yukarıdaki gelişmiş senaryoda, bu yönlendirme URI'sini işlevlerimizin URI'sine ve ardından "/.auth/login/aad/callback" olarak ayarladık.