Azure İşlevleri ve Azure AD yetkilendirmesi

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ıyla ilgili son gönderide, İşlev Uygulamamız için kimlik doğrulamanın nasıl gerekli olacağına baktık. Artık fonksiyonumuza kimlerin eriştiğini biliyoruz, Yetkilendirmeye bir göz atmanın zamanı geldi, yani artık kim olduklarını bildiğimize göre onları içeri almalı mıyız?

Seçilen kullanıcılara erişimi kısıtla

Uygulama şu anda kurulu olduğundan, ekspres veya gelişmiş modu kullanmış olsak da, kayıtlı herhangi bir uygulama, kullanıcı veya kiracımızın misafir kullanıcısı şu anda uygulamamızda oturum açabilir. Şu ana kadar sadece Kimlik Doğrulama kısmını yapılandırdık. Şimdi bazı temel Yetkilendirmelere bir göz atalım.

İşlev Uygulamamızı daha da güvenli hale getirmek için yalnızca kullanıcının kimlik doğrulamasını talep etmeyeceğiz, aynı zamanda bu kullanıcının yetkili olmasını da isteyeceğiz veya basit bir ifadeyle yalnızca seçilen kullanıcıları kabul etmek istiyoruz.

Yetkilendirmeyi yapılandırırken ilk adım, erişimi seçilen bir kullanıcı grubuna kısıtlamaktır. Azure AD bunun için yerleşik bir desteğe sahiptir ve bunu yalnızca uygulamamızı yapılandırarak açmamız gerekir.

Bu, Azure AD'deki Kurumsal Uygulamalar'a giderek, uygulamanızı bulup, özelliklere gidip "Kullanıcı ataması gerekli mi?" özelliğini ayarlayarak portalda yapılabilir. “Evet”e.

Azure CLI ile de yapılabilir:

$ServerAppId = 'c491d3f8-0d15-4ea5-96fd-957601d579fa'
az ad sp update --id $ServerAppId --set appRoleAssignmentRequired=true

Uygulamama göz atmaya çalıştığımda artık bana "Bu dizini veya sayfayı görüntüleme izniniz yok" mesajını vermeli.

Tekrar erişim elde etmek için her kullanıcıyı uygulamaya ekleyin. Bunu Azure Portal'da Azure Active Directory -> Kurumsal Uygulamalar'a giderek uygulamamızı bulabilir ve “Kullanıcılar ve Gruplar” altında uygulamamıza erişmesine izin verilmesi gereken tüm kullanıcıları ekleyebiliriz.

Bunu Microsoft Graph API'sini kullanarak da yapabiliriz. Yine bu örnekte PowerShell'den Graph'ı çağırmak için Azure CLI'yi kullanıyoruz.

Öncelikle uygulamamızın uygulama kimliğini (clientId) ve kullanıcımızın kullanıcı adını değişkenlere kaydediyoruz. Daha sonra hizmet sorumlumuzu (portalda Kurumsal Uygulama olarak adlandırılır) almak için az ad sp show'u kullanırız. Microsoft Graph'a üç şey göndermemiz gerekiyor; ResourcesId (hizmet sorumlusunun objectID'si),PrincipalId (kullanıcımızın objectId'si) ve atamak istediğimiz rolün id'si.

Bir dakika, rol? Hiç rol oluşturmadık mı?

Hayır, herhangi bir rol oluşturmadık ve eğer hizmet sorumlumuz/Enterprice Uygulamamızın herhangi bir rolü yoksa, portalda "Varsayılan Erişim" adı verilen bir şey var, boş bir kılavuz (") kullanarak buna referans verebiliriz. 00000000-0000-0000-0000-000000000000").

Son bir not olarak, ters eğik çizgi (\) ile tüm tırnak işaretlerinden (") kaçmak için gövdemizi bir kez daha ConvertTo-Json'a iki kez aktarıyoruz.

Bu kadar konuşma yeter, işte kod:

$AppId = 'c491d3f8-0d15-4ea5-96fd-957601d579fa'
$UserPrincipalName = '[email '

$App = az ad sp show --id $AppId | ConvertFrom-Json
$principalId = az ad user show --id $UserPrincipalName --query 'objectId' -o tsv

$Body = @{
    appRoleId = [Guid]::Empty.Guid
    principalId = $principalId
    resourceId = $App.objectId
} | ConvertTo-Json -Compress | ConvertTo-Json
az rest --method post --uri "https://graph.microsoft.com/v1.0/users/$UserPrincipalName/appRoleAssignments" --body $Body --headers "Content-Type=application/json"

İşte bu çok kullanışlı! Peki ya özel roller oluşturmak istersem? Ne oldu? Yapabilirsiniz!

Özel roller kullanarak yetkilendirme

Hadi bazı özel uygulama rolleri oluşturalım! Neden? Bu roller erişim belirtecinde mevcut olacak ve bir isteğe izin verilip verilmediğini belirlemek için işlev kodumuzda kullanılabilir.

Herhangi bir role ihtiyacınız yoksa bu kısmı atlayıp yukarıdaki gibi boş bir GUID 00000000-0000-0000-0000-000000000000 ile temsil edilen “Varsayılan Erişim” rolünü kullanmaya devam edebilirsiniz. Herhangi bir özel rol oluşturursanız "Varsayılan Erişim" rolü artık kullanılamayacaktır. DefaultAccess'i tanımlanmış rollere sahip bir uygulamaya atamaya çalışmak, şunu belirten bir hata mesajıyla sonuçlanacaktır: Atanan izin uygulamada bulunamadı

Özel bir rol oluşturma zamanı! Hangi tür nesnelerin bu role sahip olabileceğini belirtmemiz, role bir açıklama, görünen ad, kimlik ve değer vermemiz gerekiyor. Değer, rol adıdır ve kimliğin benzersiz bir GUID olması gerekir. Yeni bir GUID oluşturacak [guid]::NewGuid().Guid kullanıyorum.

İşte bir örnek:

$AppId = 'c491d3f8-0d15-4ea5-96fd-957601d579fa'
# Add app role to an app
$AppRole = @{
    allowedMemberTypes = @('User')
    description = 'Example of custom role'
    displayName = 'CustomRole'
    id = [guid]::NewGuid().Guid
    isEnabled = $true
    value = 'Custom'
} | ConvertTo-Json -Compress | ConvertTo-Json

# Update enterprise application
az ad sp update --id $AppId --add appRoles $AppRole

Bir AppRole'un nasıl tanımlandığı burada belgelenmiştir:
https://docs.microsoft.com/graph/api/resources/approle?view=graph-rest-1.0

Bir rol ayarladıktan sonra onu bir kullanıcıya atayabiliriz. Bu, yukarıdakine benzer şekilde yapılır. Tek yeni şey, artık boş bir GUID kullanmak yerine uygulama rolü kimliğini $App.appRoles içinde aramamızdır.

$AppId = 'c491d3f8-0d15-4ea5-96fd-957601d579fa'
$AppRoleValue = 'Custom'
$UserPrincipalName = '[email '

$App = az ad sp show --id $AppId | ConvertFrom-Json
$principalId = az ad user show --id $UserPrincipalName --query 'objectId' -o tsv

$Body = @{
    appRoleId = $App.appRoles.where{$_.Value -eq $AppRoleValue}.id
    principalId = $principalId
    resourceId = $App.objectId
} | ConvertTo-Json -Compress | ConvertTo-Json
az rest --method post --uri "https://graph.microsoft.com/beta/users/$UserPrincipalName/appRoleAssignments" --body $Body --headers "Content-Type=application/json"

Bir Web API'sinin nasıl korunacağı hakkında daha fazla bilgi için Korumalı web API'si ve Web API'lerini çağıran bir web API'si senaryolarına bakın.

Kodunuzdaki roller doğrulanıyor

Uygulama Hizmetlerinin kolay kimlik doğrulama özelliğini kullanarak belirteç doğrulaması bizim için yapılır ve bunun çoğunu halletmemize gerek yoktur, ancak ayrı rolleri doğrulamak istiyorsak yine de kimlik belirtecinin kodunu çözmemiz ve roller bölümünü çıkarmamız gerekir. .

Bu hiç de göründüğü kadar zor değil. Kimlik belirtecini x-ms-token-aad-id-token adı verilen bir başlıkta alıyoruz. Kolay kimlik doğrulama, bu başlığın kullanıcı tarafından sağlanamayacağını ve yalnızca kolay kimlik doğrulama ile sağlanabilmesini sağlar, böylece başlığa güvenebiliriz.

Bir JWT jetonunun kodunu çözmek için aşağıdaki işlevi kullanıyorum.

function ConvertFrom-JwtToken {
    [CmdletBinding()]
    param (
        [Parameter(Mandatory, ValueFromPipeline)]
        [string]
        $Token
    )
    
    process {
        $DecodedToken = $Token.Replace('-', '+').Replace('_', '/')

        $Header,$Payload,$Signature = $DecodedToken.Split('.') | ForEach-Object -Process {
            $String = $_
            switch($String.Length % 4) {
                0 {$String;break}
                1 {throw 'Invalid token'}
                2 {"$String==";break}
                3 {"$String=";break}
            }
        }

        [pscustomobject][ordered]@{
            Header = [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($Header)) | ConvertFrom-Json
            Payload = [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($Payload)) | ConvertFrom-Json
            Signature = [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($Signature))

        }

    }

}

İstek nesnesindeki Azure İşlevleri'ndeki başlıklara erişebiliriz; burada kimlik belirtecine erişmenin, kodunu çözmenin ve bir kullanıcının rollerini yazdırmanın bir örneği verilmiştir:

$IDToken = $Request.Headers.'x-ms-token-aad-id-token' | ConvertFrom-JwtToken
$Roles = $IDToken.Payload.Roles
Write-Output $Roles

İlgili makaleler