Grup Microsoft Entra (ME-ID), Peran Administrator, dan Peran Aplikasi

Artikel ini menjelaskan cara mengonfigurasi Blazor WebAssembly untuk menggunakan grup dan peran ID Microsoft Entra.

Microsoft Entra (ME-ID) menyediakan beberapa pendekatan otorisasi yang dapat dikombinasikan dengan ASP.NET Core Identity:

• Kelompok
  • Keamanan
  • Microsoft 365
  • Distribusi
• Peran
  • Peran Administrator ME-ID
  • Peran aplikasi

Panduan dalam artikel ini berlaku untuk Blazor WebAssembly skenario penyebaran ME-ID yang dijelaskan dalam topik berikut:

• Mandiri dengan Akun Microsoft
• Mandiri dengan ME-ID

Panduan artikel ini menyediakan instruksi untuk aplikasi klien dan server:

• KLIEN: Aplikasi mandiri Blazor WebAssembly .
• SERVER: ASP.NET aplikasi API/API web server Core. Anda dapat mengabaikan panduan SERVER di seluruh artikel untuk aplikasi mandiri Blazor WebAssembly .

Contoh dalam artikel ini memanfaatkan fitur .NET/C# baru. Saat menggunakan contoh dengan .NET 7 atau yang lebih lama, modifikasi kecil diperlukan. Namun, contoh teks dan kode yang berkaitan dengan berinteraksi dengan ME-ID dan Microsoft Graph sama untuk semua versi ASP.NET Core.

Prasyarat

Panduan dalam artikel ini mengimplementasikan Microsoft Graph API per panduan Graph SDK dalam Menggunakan Graph API dengan ASP.NET Core Blazor WebAssembly. Ikuti panduan implementasi Graph SDK untuk mengonfigurasi aplikasi dan mengujinya untuk mengonfirmasi bahwa aplikasi dapat memperoleh data Graph API untuk akun pengguna uji. Selain itu, lihat artikel keamanan api Graph artikel lintas tautan untuk meninjau konsep keamanan Microsoft Graph.

Saat menguji dengan Graph SDK secara lokal, sebaiknya gunakan sesi browser in-private/incognito baru untuk setiap pengujian agar tidak cookiemengganggu pengujian. Untuk informasi selengkapnya, lihat Mengamankan aplikasi mandiri ASP.NET Core Blazor WebAssembly dengan ID Microsoft Entra.

Cakupan

Untuk mengizinkan panggilan Microsoft Graph API untuk profil pengguna, penetapan peran, dan data keanggotaan grup:

• Aplikasi KLIEN dikonfigurasi dengan cakupan yang didelegasikan User.Read (https://graph.microsoft.com/User.Read) di portal Azure karena akses untuk membaca data pengguna ditentukan oleh cakupan yang diberikan (didelegasikan) kepada pengguna individual.
• Aplikasi SERVER dikonfigurasi dengan cakupan aplikasi GroupMember.Read.All (https://graph.microsoft.com/GroupMember.Read.All) di portal Azure karena akses adalah untuk aplikasi guna mendapatkan informasi tentang keanggotaan grup, bukan berdasarkan otorisasi pengguna individual untuk mengakses data tentang anggota grup.

Cakupan sebelumnya diperlukan selain cakupan yang diperlukan dalam skenario penyebaran ME-ID yang dijelaskan oleh topik yang tercantum sebelumnya (Mandiri dengan Akun Microsoft atau Mandiri dengan ME-ID).

Untuk informasi selengkapnya, lihat Gambaran Umum izin dan persetujuan di platform identitas Microsoft dan Gambaran Umum izin Microsoft Graph.

Catatan

Kata "izin" dan "cakupan" digunakan secara bergantian di portal Azure dan di berbagai set dokumentasi Microsoft dan eksternal. Artikel ini menggunakan kata "cakupan" di seluruh untuk izin yang ditetapkan ke aplikasi di portal Azure.

Atribut Klaim Keanggotaan Grup

Dalam manifes aplikasi di portal Azure untuk aplikasi KLIEN dan SERVER, atur groupMembershipClaims atribut ke All. Nilai All hasil dalam ME-ID yang mengirim semua grup keamanan, grup distribusi, dan peran pengguna yang masuk dalam klaim ID terkenal (wids):

1. Buka pendaftaran portal Azure aplikasi.
2. Pilih Kelola>Manifes di bar samping.
3. groupMembershipClaims Temukan atribut .
4. Atur nilai ke All ("groupMembershipClaims": "All").
5. Pilih tombol Simpan jika Anda membuat perubahan.

Akun pengguna kustom

Tetapkan pengguna ke grup keamanan ME-ID dan Peran Administrator ME-ID di portal Azure.

Contoh dalam artikel ini:

• Asumsikan bahwa pengguna ditetapkan ke peran Administrator Penagihan ME-ID di penyewa ME-ID portal Azure untuk otorisasi guna mengakses data API server.
• Gunakan kebijakan otorisasi untuk mengontrol akses dalam aplikasi KLIEN dan SERVER .

Di aplikasi KLIEN, perluas RemoteUserAccount untuk menyertakan properti untuk:

• Roles: Array Peran Aplikasi ME-ID (tercakup di bagian Peran Aplikasi)
• Wids: Peran Administrator ME-ID dalam klaim ID terkenal (wids)
• Oid: Klaim pengidentifikasi objek yang tidak dapat diubah (oid) (secara unik mengidentifikasi pengguna di dalam dan di seluruh penyewa)

CustomUserAccount.cs:

using System.Text.Json.Serialization;
using Microsoft.AspNetCore.Components.WebAssembly.Authentication;

namespace BlazorSample;

public class CustomUserAccount : RemoteUserAccount
{
    [JsonPropertyName("roles")]
    public List<string>? Roles { get; set; }

    [JsonPropertyName("wids")]
    public List<string>? Wids { get; set; }

    [JsonPropertyName("oid")]
    public string? Oid { get; set; }
}

Tambahkan referensi paket ke aplikasi KLIEN untuk Microsoft.Graph.

Catatan

Untuk panduan tentang menambahkan paket ke aplikasi .NET, lihat artikel di bagian Menginstal dan mengelola paket di Alur kerja konsumsi paket (dokumentasi NuGet). Konfirmasikan versi paket yang benar di NuGet.org.

Tambahkan kelas dan konfigurasi utilitas Graph SDK dalam panduan Graph SDK dari artikel Gunakan Graph API dengan ASP.NET Core Blazor WebAssembly . User.Read Tentukan cakupan untuk token akses seperti yang ditunjukkan artikel dalam file contohnyawwwroot/appsettings.json.

Tambahkan pabrik akun pengguna kustom berikut ke aplikasi KLIEN . Pabrik pengguna kustom digunakan untuk membuat:

• Klaim Peran Aplikasi (appRole) (tercakup di bagian Peran Aplikasi).
• Klaim Peran Administrator ME-ID (directoryRole).
• Contoh klaim data profil pengguna untuk nomor ponsel pengguna (mobilePhone) dan lokasi kantor (officeLocation).
• Klaim Grup ME-ID (directoryGroup).
• ILogger (logger) untuk kenyamanan jika Anda ingin mencatat informasi atau kesalahan.

CustomAccountFactory.cs:

Contoh berikut mengasumsikan bahwa file pengaturan aplikasi proyek menyertakan entri untuk URL dasar:

{
  "MicrosoftGraph": {
    "BaseUrl": "https://graph.microsoft.com/{VERSION}",
    ...
  }
}

Dalam contoh sebelumnya, {VERSION} tempat penampung adalah versi MS Graph API (misalnya: v1.0).

using System.Security.Claims;
using Microsoft.AspNetCore.Components.WebAssembly.Authentication;
using Microsoft.AspNetCore.Components.WebAssembly.Authentication.Internal;
using Microsoft.Graph;
using Microsoft.Kiota.Abstractions.Authentication;

namespace BlazorSample;

public class CustomAccountFactory(IAccessTokenProviderAccessor accessor,
        IServiceProvider serviceProvider,
        ILogger<CustomAccountFactory> logger,
        IConfiguration config)
    : AccountClaimsPrincipalFactory<CustomUserAccount>(accessor)
{
    private readonly ILogger<CustomAccountFactory> logger = logger;
    private readonly IServiceProvider serviceProvider = serviceProvider;
    private readonly string? baseUrl = 
        config.GetSection("MicrosoftGraph")["BaseUrl"];

    public override async ValueTask<ClaimsPrincipal> CreateUserAsync(
        CustomUserAccount account,
        RemoteAuthenticationUserOptions options)
    {
        var initialUser = await base.CreateUserAsync(account, options);

        if (initialUser.Identity is not null &&
            initialUser.Identity.IsAuthenticated)
        {
            var userIdentity = initialUser.Identity as ClaimsIdentity;

            if (userIdentity is not null && !string.IsNullOrEmpty(baseUrl))
            {
                account?.Roles?.ForEach((role) =>
                {
                    userIdentity.AddClaim(new Claim("appRole", role));
                });

                account?.Wids?.ForEach((wid) =>
                {
                    userIdentity.AddClaim(new Claim("directoryRole", wid));
                });

                try
                {
                    var client = new GraphServiceClient(
                        new HttpClient(),
                        serviceProvider
                            .GetRequiredService<IAuthenticationProvider>(),
                        baseUrl);

                    var user = await client.Me.GetAsync();

                    if (user is not null)
                    {
                        userIdentity.AddClaim(new Claim("mobilephone",
                            user.MobilePhone ?? "(000) 000-0000"));
                        userIdentity.AddClaim(new Claim("officelocation",
                            user.OfficeLocation ?? "Not set"));
                    }

                    var requestMemberOf = client.Users[account?.Oid].MemberOf;
                    var memberships = await requestMemberOf.Request().GetAsync();

                    if (memberships is not null)
                    {
                        foreach (var entry in memberships)
                        {
                            if (entry.ODataType == "#microsoft.graph.group")
                            {
                                userIdentity.AddClaim(
                                    new Claim("directoryGroup", entry.Id));
                            }
                        }
                    }
                }
                catch (AccessTokenNotAvailableException exception)
                {
                    exception.Redirect();
                }
            }
        }

        return initialUser;
    }
}

using System.Security.Claims;
using Microsoft.AspNetCore.Components.WebAssembly.Authentication;
using Microsoft.AspNetCore.Components.WebAssembly.Authentication.Internal;
using Microsoft.Graph;

namespace BlazorSample;

public class CustomAccountFactory(IAccessTokenProviderAccessor accessor,
        IServiceProvider serviceProvider,
        ILogger<CustomAccountFactory> logger)
    : AccountClaimsPrincipalFactory<CustomUserAccount>(accessor)
{
    private readonly ILogger<CustomAccountFactory> logger = logger;
    private readonly IServiceProvider serviceProvider = serviceProvider;

    public override async ValueTask<ClaimsPrincipal> CreateUserAsync(
        CustomUserAccount account,
        RemoteAuthenticationUserOptions options)
    {
        var initialUser = await base.CreateUserAsync(account, options);

        if (initialUser.Identity is not null &&
            initialUser.Identity.IsAuthenticated)
        {
            var userIdentity = initialUser.Identity as ClaimsIdentity;

            if (userIdentity is not null)
            {
                account?.Roles?.ForEach((role) =>
                {
                    userIdentity.AddClaim(new Claim("appRole", role));
                });

                account?.Wids?.ForEach((wid) =>
                {
                    userIdentity.AddClaim(new Claim("directoryRole", wid));
                });

                try
                {
                    var client = ActivatorUtilities
                        .CreateInstance<GraphServiceClient>(serviceProvider);
                    var request = client.Me.Request();
                    var user = await request.GetAsync();

                    if (user is not null)
                    {
                        userIdentity.AddClaim(new Claim("mobilephone",
                            user.MobilePhone ?? "(000) 000-0000"));
                        userIdentity.AddClaim(new Claim("officelocation",
                            user.OfficeLocation ?? "Not set"));
                    }

                    var requestMemberOf = client.Users[account?.Oid].MemberOf;
                    var memberships = await requestMemberOf.Request().GetAsync();

                    if (memberships is not null)
                    {
                        foreach (var entry in memberships)
                        {
                            if (entry.ODataType == "#microsoft.graph.group")
                            {
                                userIdentity.AddClaim(
                                    new Claim("directoryGroup", entry.Id));
                            }
                        }
                    }
                }
                catch (AccessTokenNotAvailableException exception)
                {
                    exception.Redirect();
                }
            }
        }

        return initialUser;
    }
}

Kode sebelumnya tidak menyertakan keanggotaan transitif. Jika aplikasi memerlukan klaim keanggotaan grup langsung dan transitif, ganti MemberOf properti (IUserMemberOfCollectionWithReferencesRequestBuilder) dengan TransitiveMemberOf (IUserTransitiveMemberOfCollectionWithReferencesRequestBuilder).

Kode sebelumnya mengabaikan klaim keanggotaan grup (groups) yang merupakan Peran Administrator ME-ID (#microsoft.graph.directoryRole jenis) karena nilai GUID yang dikembalikan oleh platform identitas Microsoft adalah ID entitas Peran Administrator ME-ID dan bukan ID Templat Peran. ID entitas tidak stabil di seluruh penyewa di platform identitas Microsoft dan tidak boleh digunakan untuk membuat kebijakan otorisasi untuk pengguna di aplikasi. Selalu gunakan ID Templat Peran untuk Peran Administrator ME-ID yang disediakan oleh wids klaim.

Di aplikasi KLIEN, konfigurasikan autentikasi MSAL untuk menggunakan pabrik akun pengguna kustom.

Konfirmasikan bahwa Program file menggunakan Microsoft.AspNetCore.Components.WebAssembly.Authentication namespace layanan:

using Microsoft.AspNetCore.Components.WebAssembly.Authentication;

AddMsalAuthentication Perbarui panggilan ke yang berikut ini. Perhatikan bahwa Blazor kerangka kerja RemoteUserAccount digantikan oleh aplikasi CustomUserAccount untuk autentikasi MSAL dan pabrik utama klaim akun:

builder.Services.AddMsalAuthentication<RemoteAuthenticationState,
    CustomUserAccount>(options =>
    {
        builder.Configuration.Bind("AzureAd",
            options.ProviderOptions.Authentication);
    })
    .AddAccountClaimsPrincipalFactory<RemoteAuthenticationState, CustomUserAccount,
        CustomAccountFactory>();

Konfirmasikan keberadaan kode Graph SDK yang dijelaskan oleh artikel Gunakan Graph API dengan ASP.NET Core Blazor WebAssembly dan bahwa wwwroot/appsettings.json konfigurasi sudah benar sesuai panduan Graph SDK :

var baseUrl = string.Join("/", 
    builder.Configuration.GetSection("MicrosoftGraph")["BaseUrl"], 
    builder.Configuration.GetSection("MicrosoftGraph")["Version"]);
var scopes = builder.Configuration.GetSection("MicrosoftGraph:Scopes")
    .Get<List<string>>();

builder.Services.AddGraphClient(baseUrl, scopes);

wwwroot/appsettings.json:

{
  "MicrosoftGraph": {
    "BaseUrl": "https://graph.microsoft.com",
    "Version: "v1.0",
    "Scopes": [
      "user.read"
    ]
  }
}

Konfigurasi otorisasi

Di aplikasi KLIEN, buat kebijakan untuk setiap Peran Aplikasi, Peran Administrator ME-ID, atau grup keamanan dalam Program file. Contoh berikut membuat kebijakan untuk peran Administrator Penagihan ME-ID:

builder.Services.AddAuthorizationCore(options =>
{
    options.AddPolicy("BillingAdministrator", policy => 
        policy.RequireClaim("directoryRole", 
            "b0f54661-2d74-4c50-afa3-1ec803f12efe"));
});

Untuk daftar lengkap ID untuk Peran Administrator ME-ID, lihat ID templat peran dalam dokumentasi Entra. Untuk informasi selengkapnya tentang kebijakan otorisasi, lihat Otorisasi berbasis kebijakan di ASP.NET Core.

Dalam contoh berikut, aplikasi KLIEN menggunakan kebijakan sebelumnya untuk mengotorisasi pengguna.

Komponen AuthorizeView bekerja dengan kebijakan:

<AuthorizeView Policy="BillingAdministrator">
    <Authorized>
        <p>
            The user is in the 'Billing Administrator' ME-ID Administrator Role
            and can see this content.
        </p>
    </Authorized>
    <NotAuthorized>
        <p>
            The user is NOT in the 'Billing Administrator' role and sees this
            content.
        </p>
    </NotAuthorized>
</AuthorizeView>

Akses ke seluruh komponen dapat didasarkan pada kebijakan menggunakan [Authorize] direktif atribut (AuthorizeAttribute):

@page "/"
@using Microsoft.AspNetCore.Authorization
@attribute [Authorize(Policy = "BillingAdministrator")]

Jika pengguna tidak diotorisasi, mereka akan diarahkan ke halaman masuk ME-ID.

Pemeriksaan kebijakan juga dapat dilakukan dalam kode dengan logika prosedural.

CheckPolicy.razor:

@page "/checkpolicy"
@using Microsoft.AspNetCore.Authorization
@inject IAuthorizationService AuthorizationService

<h1>Check Policy</h1>

<p>This component checks a policy in code.</p>

<button @onclick="CheckPolicy">Check 'BillingAdministrator' policy</button>

<p>Policy Message: @policyMessage</p>

@code {
    private string policyMessage = "Check hasn't been made yet.";

    [CascadingParameter]
    private Task<AuthenticationState> authenticationStateTask { get; set; }

    private async Task CheckPolicy()
    {
        var user = (await authenticationStateTask).User;

        if ((await AuthorizationService.AuthorizeAsync(user, 
            "BillingAdministrator")).Succeeded)
        {
            policyMessage = "Yes! The 'BillingAdministrator' policy is met.";
        }
        else
        {
            policyMessage = "No! 'BillingAdministrator' policy is NOT met.";
        }
    }
}

Mengotorisasi akses API server/API web

Aplikasi API SERVER dapat memberi otorisasi kepada pengguna untuk mengakses titik akhir API yang aman dengan kebijakan otorisasi untuk grup keamanan, Peran Administrator ME-ID, dan Peran Aplikasi saat token akses berisi groups, , widsdan role klaim. Contoh berikut membuat kebijakan untuk peran Administrator Penagihan ME-ID dalam Program file menggunakan wids klaim (ID terkenal/ID Templat Peran):

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("BillingAdministrator", policy => 
        policy.RequireClaim("wids", "b0f54661-2d74-4c50-afa3-1ec803f12efe"));
});

Untuk daftar lengkap ID untuk Peran Administrator ME-ID, lihat ID templat peran dalam dokumentasi Azure. Untuk informasi selengkapnya tentang kebijakan otorisasi, lihat Otorisasi berbasis kebijakan di ASP.NET Core.

Akses ke pengontrol di aplikasi SERVER dapat didasarkan pada penggunaan [Authorize] atribut dengan nama kebijakan (dokumentasi API: AuthorizeAttribute).

Contoh berikut membatasi akses ke data tagihan dari BillingDataController ke Administrator Penagihan Azure dengan nama BillingAdministratorkebijakan :

using Microsoft.AspNetCore.Authorization;

[Authorize(Policy = "BillingAdministrator")]
[ApiController]
[Route("[controller]")]
public class BillingDataController : ControllerBase
{
    ...
}

Untuk informasi lebih lanjut, lihat Otorisasi berbasis kebijakan di ASP.NET Core.

Peran aplikasi

Untuk mengonfigurasi aplikasi di portal Azure untuk memberikan klaim keanggotaan Peran Aplikasi, lihat Menambahkan peran aplikasi ke aplikasi Anda dan menerimanya dalam token dalam dokumentasi Entra.

Contoh berikut mengasumsikan bahwa aplikasi KLIEN dan SERVER dikonfigurasi dengan dua peran, dan peran ditetapkan ke pengguna uji:

• Admin
• Developer

Catatan

Saat mengembangkan sepasang aplikasi mandiri server klien (aplikasi mandiri Blazor WebAssembly dan aplikasi API server Inti/API web ASP.NET), appRoles properti manifes klien dan server portal Azure pendaftaran aplikasi harus menyertakan peran yang dikonfigurasi yang sama. Setelah membuat peran dalam manifes aplikasi klien, salin secara keseluruhan ke manifes aplikasi server. Jika Anda tidak mencerminkan manifes appRoles antara pendaftaran aplikasi klien dan server, klaim peran tidak dibuat untuk pengguna terautentikasi api server/API web, bahkan jika token akses mereka memiliki entri yang benar dalam role klaim.

Meskipun Anda tidak dapat menetapkan peran ke grup tanpa akun Microsoft Entra ID Premium, Anda dapat menetapkan peran kepada pengguna dan menerima role klaim untuk pengguna dengan akun Azure standar. Panduan di bagian ini tidak memerlukan akun ME-ID Premium.

Jika Anda memiliki akun Azure tingkat Premium, peran Kelola>Aplikasi muncul di bilah sisi pendaftaran aplikasi portal Azure. Ikuti panduan di Menambahkan peran aplikasi ke aplikasi Anda dan menerimanya dalam token untuk mengonfigurasi peran aplikasi.

Jika Anda tidak memiliki akun Azure tingkat Premium, edit manifes aplikasi di portal Azure. Ikuti panduan dalam Peran aplikasi: Implementasi untuk menetapkan peran aplikasi secara manual dalam appRoles entri file manifes. Simpan perubahan pada file.

Berikut ini adalah contoh appRoles entri yang membuat Admin dan Developer peran. Contoh peran ini digunakan nanti dalam contoh bagian ini di tingkat komponen untuk menerapkan pembatasan akses:

"appRoles": [
  {
    "allowedMemberTypes": [
      "User"
    ],
    "description": "Administrators manage developers.",
    "displayName": "Admin",
    "id": "584e483a-7101-404b-9bb1-83bf9463e335",
    "isEnabled": true,
    "lang": null,
    "origin": "Application",
    "value": "Admin"
  },
  {
    "allowedMemberTypes": [
      "User"
    ],
    "description": "Developers write code.",
    "displayName": "Developer",
    "id": "82770d35-2a93-4182-b3f5-3d7bfe9dfe46",
    "isEnabled": true,
    "lang": null,
    "origin": "Application",
    "value": "Developer"
  }
],

Catatan

Anda dapat menghasilkan GUID dengan program generator GUID online (hasil pencarian Google untuk "generator guid").

Untuk menetapkan peran kepada pengguna (atau grup jika Anda memiliki akun Azure tingkat Premium):

1. Navigasikan ke aplikasi Enterprise di area ME-ID portal Azure.
2. Pilih aplikasi. Pilih Kelola>Pengguna dan grup dari bar samping.
3. Pilih kotak centang untuk satu atau beberapa akun pengguna.
4. Dari menu di atas daftar pengguna, pilih Edit penugasan.
5. Untuk entri Pilih peran, pilih Tidak ada yang dipilih.
6. Pilih peran dari daftar dan gunakan tombol Pilih untuk memilihnya.
7. Gunakan tombol Tetapkan di bagian bawah layar untuk menetapkan peran.

Beberapa peran ditetapkan dalam portal Azure dengan menambahkan kembali pengguna untuk setiap penetapan peran tambahan. Gunakan tombol Tambahkan pengguna/grup di bagian atas daftar pengguna untuk menambahkan kembali pengguna. Gunakan langkah-langkah sebelumnya untuk menetapkan peran lain kepada pengguna. Anda dapat mengulangi proses ini sebanyak yang diperlukan untuk menambahkan peran tambahan ke pengguna (atau grup).

Yang CustomAccountFactory diperlihatkan di bagian Akun pengguna kustom disiapkan untuk bertindak berdasarkan role klaim dengan JSnilai array ON. Tambahkan dan daftarkan di aplikasi KLIEN seperti yang CustomAccountFactory ditunjukkan di bagian Akun pengguna kustom. Tidak perlu memberikan kode untuk menghapus klaim asli role karena secara otomatis dihapus oleh kerangka kerja.

Program Dalam file aplikasi KLIEN, tentukan klaim bernama "appRole" sebagai klaim peran untuk ClaimsPrincipal.IsInRole pemeriksaan:

builder.Services.AddMsalAuthentication(options =>
{
    ...

    options.UserOptions.RoleClaim = "appRole";
});

Catatan

Jika Anda lebih suka menggunakan directoryRoles klaim (TAMBAHKAN Peran Administrator), tetapkan "directoryRoles" ke RemoteAuthenticationUserOptions.RoleClaim.

Program Dalam file aplikasi SERVER, tentukan klaim bernama "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" sebagai klaim peran untuk ClaimsPrincipal.IsInRole pemeriksaan:

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApi(options =>
    {
        Configuration.Bind("AzureAd", options);
        options.TokenValidationParameters.RoleClaimType = 
            "http://schemas.microsoft.com/ws/2008/06/identity/claims/role";
    },
    options => { Configuration.Bind("AzureAd", options); });

Catatan

Ketika skema autentikasi tunggal terdaftar, skema autentikasi secara otomatis digunakan sebagai skema default aplikasi, dan tidak perlu menyatakan skema ke AddAuthentication atau melalui AuthenticationOptions. Untuk informasi selengkapnya, lihat Gambaran Umum Autentikasi Inti ASP.NET dan pengumuman ASP.NET Core (aspnet/Pengumuman #490).

Catatan

Jika Anda lebih suka menggunakan wids klaim (TAMBAHKAN Peran Administrator), tetapkan "wids" ke TokenValidationParameters.RoleClaimType.

Setelah Anda menyelesaikan langkah-langkah sebelumnya untuk membuat dan menetapkan peran kepada pengguna (atau grup jika Anda memiliki akun Azure tingkat Premium) dan menerapkan CustomAccountFactory dengan Graph SDK, seperti yang dijelaskan sebelumnya dalam artikel ini dan dalam Menggunakan Graph API dengan ASP.NET Core Blazor WebAssembly, Anda akan melihat appRole klaim untuk setiap peran yang ditetapkan bahwa pengguna yang masuk ditetapkan (atau peran yang ditetapkan ke grup tempat mereka menjadi anggota). Jalankan aplikasi dengan pengguna uji untuk mengonfirmasi klaim ada seperti yang diharapkan. Saat menguji dengan Graph SDK secara lokal, sebaiknya gunakan sesi browser in-private/incognito baru untuk setiap pengujian agar tidak cookiemengganggu pengujian. Untuk informasi selengkapnya, lihat Mengamankan aplikasi mandiri ASP.NET Core Blazor WebAssembly dengan ID Microsoft Entra.

Pendekatan otorisasi komponen berfungsi pada saat ini. Salah satu mekanisme otorisasi dalam komponen aplikasi KLIEN dapat menggunakan Admin peran untuk mengotorisasi pengguna:

• AuthorizeView komponen

  <AuthorizeView Roles="Admin">
  

• [Authorize] direktif atribut (AuthorizeAttribute)

  @attribute [Authorize(Roles = "Admin")]
  

• Logika prosedural

  var authState = await AuthenticationStateProvider.GetAuthenticationStateAsync();
  var user = authState.User;
  
  if (user.IsInRole("Admin")) { ... }
  

Beberapa pengujian peran didukung:

• Mengharuskan pengguna berada dalam Admin peran atau Developer dengan AuthorizeView komponen:

  <AuthorizeView Roles="Admin, Developer">
      ...
  </AuthorizeView>
  

• Mengharuskan pengguna berada dalam Admin peran dan Developer dengan AuthorizeView komponen:

  <AuthorizeView Roles="Admin">
      <AuthorizeView Roles="Developer" Context="innerContext">
          ...
      </AuthorizeView>
  </AuthorizeView>
  

  Untuk informasi selengkapnya tentang Context untuk bagian dalam AuthorizeView, lihat autentikasi dan otorisasi inti Blazor ASP.NET.

• Mengharuskan pengguna berada dalam Admin peran atau Developer dengan [Authorize] atribut :

  @attribute [Authorize(Roles = "Admin, Developer")]
  

• Mengharuskan pengguna berada dalam Admin peran dan Developer dengan [Authorize] atribut :

  @attribute [Authorize(Roles = "Admin")]
  @attribute [Authorize(Roles = "Developer")]
  

• Mengharuskan pengguna berada dalam Admin peran atau Developer dengan kode prosedural:

  @code {
      private async Task DoSomething()
      {
          var authState = await AuthenticationStateProvider
              .GetAuthenticationStateAsync();
          var user = authState.User;
  
          if (user.IsInRole("Admin") || user.IsInRole("Developer"))
          {
              ...
          }
          else
          {
              ...
          }
      }
  }
  

• Wajibkan pengguna berada dalam Admin peran dan Developer dengan kode prosedural dengan mengubah OR bersyarat (||) menjadi AND bersyarat (&&) dalam contoh sebelumnya:

  if (user.IsInRole("Admin") && user.IsInRole("Developer"))
  

Salah satu mekanisme otorisasi dalam pengontrol aplikasi SERVER dapat menggunakan Admin peran untuk mengotorisasi pengguna:

• [Authorize] direktif atribut (AuthorizeAttribute)

  [Authorize(Roles = "Admin")]
  

• Logika prosedural

  if (User.IsInRole("Admin")) { ... }
  

Beberapa pengujian peran didukung:

• Mengharuskan pengguna berada dalam Admin peran atau Developer dengan [Authorize] atribut :

  [Authorize(Roles = "Admin, Developer")]
  

• Mengharuskan pengguna berada dalam Admin peran dan Developer dengan [Authorize] atribut :

  [Authorize(Roles = "Admin")]
  [Authorize(Roles = "Developer")]
  

• Mengharuskan pengguna berada dalam Admin peran atau Developer dengan kode prosedural:

  static readonly string[] scopeRequiredByApi = new string[] { "API.Access" };
  
  ...
  
  [HttpGet]
  public IEnumerable<ReturnType> Get()
  {
      HttpContext.VerifyUserHasAnyAcceptedScope(scopeRequiredByApi);
  
      if (User.IsInRole("Admin") || User.IsInRole("Developer"))
      {
          ...
      }
      else
      {
          ...
      }
  
      return ...
  }
  

• Wajibkan pengguna berada dalam Admin peran dan Developer dengan kode prosedural dengan mengubah OR bersyarat (||) menjadi AND bersyarat (&&) dalam contoh sebelumnya:

  if (User.IsInRole("Admin") && User.IsInRole("Developer"))
  

Karena perbandingan string .NET peka huruf besar/kecil secara default, nama peran yang cocok juga peka huruf besar/kecil. Misalnya, Admin (huruf Abesar ) tidak diperlakukan sebagai peran yang sama dengan admin (huruf akecil ).

Kasus Pascal biasanya digunakan untuk nama peran (misalnya, BillingAdministrator), tetapi penggunaan kasus Pascal bukan persyaratan yang ketat. Skema casing yang berbeda, seperti camel case, kebab case, dan snake case, diizinkan. Menggunakan spasi dalam nama peran juga tidak biasa tetapi diizinkan. Misalnya, billing administrator adalah format nama peran yang tidak biasa di aplikasi .NET tetapi valid.

Sumber Daya Tambahan:

• ID templat peran (dokumentasi Entra)
• groupMembershipClaims atribut (Dokumentasi Entra)
• Tambahkan peran aplikasi ke aplikasi Anda dan terima dalam token (dokumentasi Entra)
• Peran aplikasi (dokumentasi Azure)
• Otorisasi berbasis klaim di ASP.NET Core
• Otorisasi berbasis peran di ASP.NET Core
• ASP.NET Core Blazor autentikasi dan otorisasi