Biztonság: Hitelesítés és engedélyezés ASP.NET webes űrlapokon és Blazor

Tipp.

Ez a tartalom egy részlet az eBookból, Blazor az Azure-hoz készült ASP NET Web Forms Developers számára, amely elérhető a .NET Docs-on vagy egy ingyenesen letölthető PDF-fájlként, amely offline is olvasható.

PDF letöltése

Az ASP.NET Web Forms-alkalmazásból Blazor való migrálás szinte biztosan megköveteli a hitelesítés és az engedélyezés végrehajtásának frissítését, feltéve, hogy az alkalmazás hitelesítése konfigurálva van. Ez a fejezet bemutatja, hogyan migrálhat a ASP.NET Webes űrlapok univerzális szolgáltatói modellből (tagság, szerepkörök és felhasználói profilok esetén), és hogyan dolgozhat az alkalmazásokból származó Blazor ASP.NET Core Identity használatával. Bár ez a fejezet a magas szintű lépéseket és szempontokat ismerteti, a részletes lépések és szkriptek a hivatkozott dokumentációban találhatók.

ASP.NET univerzális szolgáltatók

A 2.0-s ASP.NET óta a ASP.NET Web Forms platform számos szolgáltatáshoz támogatott szolgáltatói modellt, beleértve a tagságot is. Az univerzális tagsági szolgáltató és az opcionális szerepkör-szolgáltató általában ASP.NET Web Forms-alkalmazásokkal van üzembe helyezve. Robusztus és biztonságos módszert kínál a hitelesítés és az engedélyezés kezelésére, amely ma is jól működik. Ezen univerzális szolgáltatók legújabb ajánlata NuGet-csomagként, Microsoft.AspNet.Providersként érhető el.

Az univerzális szolgáltatók olyan SQL-adatbázissémával dolgoznak, amely olyan táblákat tartalmaz, mint a aspnet_Applications, aspnet_Membership, aspnet_Rolesés aspnet_Users. Ha a aspnet_regsql.exe parancs futtatásával van konfigurálva, a szolgáltatók táblákat és tárolt eljárásokat telepítenek, amelyek biztosítják az összes szükséges lekérdezést és parancsot az alapul szolgáló adatok kezeléséhez. Az adatbázisséma és ezek a tárolt eljárások nem kompatibilisek az újabb ASP.NET identitás- és ASP.NET Core Identity-rendszerekkel, ezért a meglévő adatokat át kell telepíteni az új rendszerbe. Az 1. ábra egy univerzális szolgáltatókhoz konfigurált táblázatsémát mutat be.

Az univerzális szolgáltató kezeli a felhasználókat, a tagságot, a szerepköröket és a profilokat. A felhasználók globálisan egyedi azonosítókhoz vannak rendelve, és az olyan alapvető információk, mint a userId, a userName stb. a aspnet_Users táblában vannak tárolva. A hitelesítési adatokat, például a jelszót, a jelszóformátumot, a jelszósót, a zárolási számlálókat és a részleteket stb. a aspnet_Membership táblázat tárolja. A szerepkörök egyszerűen nevekből és egyedi azonosítókból állnak, amelyek a társítás táblán keresztül vannak hozzárendelve a aspnet_UsersInRoles felhasználókhoz, és több-a-többhöz kapcsolatot biztosítanak.

Ha a meglévő rendszer a tagságon kívül szerepköröket is használ, át kell telepítenie a felhasználói fiókokat, a kapcsolódó jelszavakat, a szerepköröket és a szerepkör-tagságot ASP.NET Core Identity-be. Emellett valószínűleg frissítenie kell a kódot, ahol jelenleg szerepkör-ellenőrzéseket végez, ha utasításokkal inkább deklaratív szűrőket, attribútumokat és/vagy címkesegítőket használ. A fejezet végén részletesebben áttekintjük a migrálással kapcsolatos szempontokat.

Engedélyezési konfiguráció a Web Formsban

A ASP.NET Web Forms-alkalmazások egyes lapjaihoz való engedélyezett hozzáférés konfigurálásához általában azt kell megadnia, hogy bizonyos lapok vagy mappák elérhetetlenek legyenek a névtelen felhasználók számára. Ez a konfiguráció a web.config fájlban történik:

<?xml version="1.0"?>
<configuration>
    <system.web>
      <authentication mode="Forms">
        <forms defaultUrl="~/home.aspx" loginUrl="~/login.aspx"
          slidingExpiration="true" timeout="2880"></forms>
      </authentication>

      <authorization>
        <deny users="?" />
      </authorization>
    </system.web>
</configuration>

A authentication konfigurációs szakasz beállítja az alkalmazás űrlaphitelesítését. A authorization szakasz arra szolgál, hogy letiltsa a névtelen felhasználókat a teljes alkalmazás számára. Azonban helyenként részletesebb engedélyezési szabályokat is megadhat, valamint szerepköralapú engedélyezési ellenőrzéseket is alkalmazhat.

<location path="login.aspx">
  <system.web>
    <authorization>
      <allow users="*" />
    </authorization>
  </system.web>
</location>

A fenti konfiguráció az elsővel kombinálva lehetővé tenné a névtelen felhasználók számára a bejelentkezési oldal elérését, felülírva a nem hitelesített felhasználókra vonatkozó webhelyszintű korlátozást.

<location path="/admin">
  <system.web>
    <authorization>
      <allow roles="Administrators" />
      <deny users="*" />
    </authorization>
  </system.web>
</location>

A fenti konfiguráció a többiekkel kombinálva korlátozza a mappa és a /admin benne lévő összes erőforrás elérését a "Rendszergazdák" szerepkör tagjai számára. Ezt a korlátozást úgy is alkalmazhatja, hogy egy külön web.config fájlt helyez el a /admin mappagyökérben.

Engedélyezési kód a Web Formsban

A hozzáférés web.configkonfigurálása mellett programozott módon is konfigurálhatja a hozzáférést és a viselkedést a Web Forms-alkalmazásban. Korlátozhatja például bizonyos műveletek elvégzésének vagy bizonyos adatok megtekintésének lehetőségét a felhasználó szerepköre alapján.

Ez a kód használható mind a kód mögötti logikában, mind a lapon:

<% if (HttpContext.Current.User.IsInRole("Administrators")) { %>
  <a href="/admin">Go To Admin</a>
<% } %>

A felhasználói szerepkör-tagság ellenőrzése mellett azt is megállapíthatja, hogy hitelesítve vannak-e (bár ezt gyakran jobb a fent tárgyalt helyalapú konfigurációval elvégezni). Az alábbiakban egy példa látható erre a megközelítésre.

protected void Page_Load(object sender, EventArgs e)
{
    if (!User.Identity.IsAuthenticated)
    {
        FormsAuthentication.RedirectToLoginPage();
    }
    if (!Roles.IsUserInRole(User.Identity.Name, "Administrators"))
    {
        MessageLabel.Text = "Only administrators can view this.";
        SecretPanel.Visible = false;
    }
}

A fenti kódban a szerepköralapú hozzáférés-vezérlés (RBAC) segítségével állapítható meg, hogy a lap egyes elemei, például az a SecretPanel) láthatóak-e az aktuális felhasználó szerepköre alapján.

Általában ASP.NET Web Forms-alkalmazások konfigurálják a web.config fájlon belüli biztonságot, majd szükség esetén további ellenőrzéseket adnak hozzá a lapokhoz .aspx és a kapcsolódó .aspx.cs kód mögötti fájlokhoz. A legtöbb alkalmazás az univerzális tagságszolgáltatót használja, gyakran a további szerepkör-szolgáltatóval.

ASP.NET Core Identity

Bár továbbra is hitelesítéssel és engedélyezéssel van megbízva, ASP.NET Core Identity más absztrakciókat és feltételezéseket használ az univerzális szolgáltatókhoz képest. Az új identitásmodell például támogatja a külső hitelesítést, így a felhasználók közösségimédia-fiókkal vagy más megbízható hitelesítésszolgáltatóval hitelesíthetik magukat. ASP.NET Core Identity támogatja a felhasználói felületet a gyakran szükséges lapokhoz, például a bejelentkezéshez, a kijelentkezéshez és a regisztrációhoz. Az EF Core-t használja az adathozzáféréshez, és EF Core-migrálásokkal hozza létre az adatmodell támogatásához szükséges sémát. A ASP.NET Core identitásának bemutatása jó áttekintést nyújt a ASP.NET Core Identity használatbavételéről. Ha még nem állította be ASP.NET Core Identity-t az alkalmazásban és annak adatbázisában, az segít az első lépésekben.

Szerepkörök, jogcímek és szabályzatok

Az univerzális szolgáltatók és a ASP.NET Core Identity egyaránt támogatják a szerepkörök fogalmát. Létrehozhat szerepköröket a felhasználók számára, és felhasználókat rendelhet hozzá a szerepkörökhöz. A felhasználók tetszőleges számú szerepkörhöz tartozhatnak, és az engedélyezési megvalósítás részeként ellenőrizheti a szerepkör-tagságot.

A szerepkörök mellett a ASP.NET Core-identitás a jogcímek és szabályzatok fogalmait is támogatja. Bár egy szerepkörnek konkrétan meg kell felelnie azoknak az erőforrásoknak, amelyekhez a felhasználónak hozzá kell férnie, a jogcímek egyszerűen a felhasználó identitásának részei. A jogcím egy névérték-pár, amely a tárgyat jelöli, nem pedig azt, amit a tulajdonos tehet.

Lehetőség van a felhasználó jogcímeinek közvetlen vizsgálatára, és ezen értékek alapján meghatározni, hogy a felhasználónak hozzáférést kell-e adni egy erőforráshoz. Az ilyen ellenőrzések azonban gyakran ismétlődőek és szétszóródnak a rendszerben. Jobb módszer egy szabályzat definiálása.

Az engedélyezési szabályzatok egy vagy több követelményből állnak. A szabályzatok az engedélyezési szolgáltatás konfigurációjának részeként vannak regisztrálva a ConfigureServices következő metódusban Startup.cs: . Az alábbi kódrészlet például egy "CanadiansOnly" nevű szabályzatot konfigurál, amelynek az a követelménye, hogy a felhasználó az Ország jogcímet a "Canada" értékkel adja meg.

services.AddAuthorization(options =>
{
    options.AddPolicy("CanadiansOnly", policy => policy.RequireClaim(ClaimTypes.Country, "Canada"));
});

A dokumentációban többet is megtudhat arról, hogyan hozhat létre egyéni szabályzatokat.

Függetlenül attól, hogy szabályzatokat vagy szerepköröket használ, megadhatja, hogy az Blazor alkalmazás egy adott lapján szükség van-e erre a szerepkörre vagy szabályzatra az [Authorize] irányelvvel alkalmazott attribútummal @attribute .

Szerepkör megkövetelése:

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

A szabályzat megkövetelése:

@attribute [Authorize(Policy ="CanadiansOnly")]

Ha hozzáférésre van szüksége a felhasználó hitelesítési állapotához, szerepköreihez vagy jogcímeihez a kódban, ennek a funkciónak két elsődleges módja van. Az első a hitelesítési állapot kaszkádolt paraméterként való fogadása. A második az állapot elérése egy injektált AuthenticationStateProvidereszközzel. Az egyes megközelítések részleteit a Blazor biztonsági dokumentáció ismerteti.

Az alábbi kód bemutatja, hogyan fogadhatja a AuthenticationState kaszkádolt paramétert:

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

Ezzel a paraméterrel a következő kóddal szerezheti be a felhasználót:

var authState = await authenticationStateTask;
var user = authState.User;

Az alábbi kód bemutatja, hogyan szúrhatja be a következőt AuthenticationStateProvider:

@using Microsoft.AspNetCore.Components.Authorization
@inject AuthenticationStateProvider AuthenticationStateProvider

A szolgáltatóval a következő kóddal férhet hozzá a felhasználóhoz:

AuthenticationState authState = await AuthenticationStateProvider.GetAuthenticationStateAsync();
ClaimsPrincipal user = authState.User;

if (user.Identity.IsAuthenticated)
{
  // work with user.Claims and/or user.Roles
}

Megjegyzés: A AuthorizeView fejezet későbbi részében tárgyalt összetevő deklaratív módon szabályozza, hogy a felhasználó mit lát egy lapon vagy összetevőn.

A felhasználókkal és jogcímekkel való munkához (a kiszolgálóalkalmazásokban Blazor ) szükség lehet egy UserManager<T> (alapértelmezett használatú IdentityUser ) fájl beszúrására is, amellyel számba vehet és módosíthat egy felhasználó jogcímeit. Először adja meg a típust, és rendelje hozzá egy tulajdonsághoz:

@inject UserManager<IdentityUser> MyUserManager

Ezután használja a felhasználó jogcímeinek használatához. Az alábbi minta bemutatja, hogyan adhat hozzá és őrizhet meg jogcímet egy felhasználón:

private async Task AddCountryClaim()
{
    var authState = await AuthenticationStateProvider.GetAuthenticationStateAsync();
    var user = authState.User;
    var identityUser = await MyUserManager.FindByNameAsync(user.Identity.Name);

    if (!user.HasClaim(c => c.Type == ClaimTypes.Country))
    {
        // stores the claim in the cookie
        ClaimsIdentity id = new ClaimsIdentity();
        id.AddClaim(new Claim(ClaimTypes.Country, "Canada"));
        user.AddIdentity(id);

        // save the claim in the database
        await MyUserManager.AddClaimAsync(identityUser, new Claim(ClaimTypes.Country, "Canada"));
    }
}

Ha szerepkörökkel kell dolgoznia, kövesse ugyanezt a megközelítést. Előfordulhat, hogy be kell szúrnia egy RoleManager<T> (alapértelmezett típushoz használt IdentityRole ) fájlt a szerepkörök listázásához és kezeléséhez.

Megjegyzés: A WebAssembly-projektekben Blazor kiszolgálói API-kat kell biztosítania a műveletek végrehajtásához (ahelyett, hogy közvetlenül vagy UserManager<T> használatban kellene lennieRoleManager<T>). A Blazor WebAssembly-ügyfélalkalmazások az erre a célra közzétett API-végpontok biztonságos meghívásával kezelhetik a jogcímeket és/vagy szerepköröket.

Migrálási útmutató

Az ASP.NET Webes űrlapok és az univerzális szolgáltatók ASP.NET Core Identity szolgáltatásba való migrálása több lépésből áll:

1. ASP.NET Core Identity-adatbázisséma létrehozása a céladatbázisban
2. Adatok áttelepítése univerzális szolgáltatói sémából ASP.NET Core Identity-sémába
3. Konfiguráció áttelepítése köztes web.config szoftverre és szolgáltatásokra, általában Program.cs (vagy osztálybanStartup)
4. Az egyes oldalak frissítése vezérlőkkel és feltételes beállításokkal címkesegítők és új identitás API-k használatával.

Az alábbi szakaszok részletesen ismertetik ezeket a lépéseket.

A ASP.NET Core Identity-séma létrehozása

A core identity ASP.NET szükséges táblastruktúra többféleképpen is létrehozható. A legegyszerűbb egy új ASP.NET Core-webalkalmazás létrehozása. Válassza a webalkalmazást, majd módosítsa a hitelesítés típusát az egyéni fiókok használatához.

A parancssorból ugyanezt a parancsot futtatva dotnet new webapp -au Individualis megteheti. Az alkalmazás létrehozása után futtassa, és regisztráljon a webhelyen. Az alábbihoz hasonló lapot kell aktiválnia:

Kattintson az "Áttelepítések alkalmazása" gombra, és létre kell hoznia a szükséges adatbázistáblákat. Emellett a migrálási fájloknak is meg kell jelennie a projektben, az alábbi módon:

A migrálást a webalkalmazás futtatása nélkül is futtathatja az alábbi parancssori eszközzel:

dotnet ef database update

Ha inkább egy szkriptet futtatna az új séma meglévő adatbázisra való alkalmazásához, ezeket a migrálásokat a parancssorból is szkriptelheti. Futtassa ezt a parancsot a szkript létrehozásához:

dotnet ef migrations script -o auth.sql

A fenti parancs létrehoz egy SQL-szkriptet a kimeneti fájlban auth.sql, amely ezután bármilyen adatbázison futtatható. Ha problémái vannak a parancsok futtatásával dotnet ef , győződjön meg arról, hogy telepítve vannak a rendszeren az EF Core-eszközök.

Abban az esetben, ha további oszlopok vannak a forrástáblákon, meg kell határoznia az új séma ezen oszlopainak legjobb helyét. A táblában aspnet_Membership található oszlopokat általában a AspNetUsers táblához kell hozzárendelni. A bekapcsolva lévő aspnet_Roles oszlopokat a gombra kell képezni AspNetRoles. A táblázat további oszlopai aspnet_UsersInRoles hozzá lesznek adva a AspNetUserRoles táblához.

Érdemes megfontolni a további oszlopok külön táblákba helyezését is. Így a jövőbeli migrálásoknak nem kell figyelembe venniük az alapértelmezett identitásséma ilyen testreszabásait.

Adatok áttelepítése univerzális szolgáltatókról ASP.NET Core Identity-be

Miután a céltábla sémája elkészült, a következő lépés a felhasználói és szerepkörrekordok áttelepítése az új sémába. A sémakülönbségek teljes listájáért, beleértve az új oszlopokhoz tartozó oszlopokat, olvassa el az Áttelepítés ASP.NET Tagság-hitelesítésről ASP.NET Core 2.0-identitásra című témakört.

Ha át szeretné migrálni a felhasználókat a tagságból az új identitástáblákba, kövesse az Áttelepítés ASP.NET Tagsági hitelesítésről ASP.NET Core 2.0-identitásra című cikkben leírt lépéseket. Miután követte ezeket a lépéseket és a megadott szkriptet, a felhasználóknak a következő bejelentkezéskor módosítaniuk kell a jelszavukat.

Lehetséges a felhasználói jelszavak migrálása, de a folyamat sokkal nagyobb szerepet játszik. Ha a felhasználókat a migrálási folyamat részeként frissíteniük kell a jelszavukat, és új, egyedi jelszavak használatára ösztönözniük kell őket, az valószínűleg növeli az alkalmazás általános biztonságát.

Biztonsági beállítások migrálása a web.config-ból az alkalmazásindításba

Ahogy korábban említettük, az ASP.NET tagság- és szerepkör-kezelők az alkalmazás web.config fájljában vannak konfigurálva. Mivel ASP.NET Core-alkalmazások nincsenek IIS-hez kötve, és külön rendszert használnak a konfigurációhoz, ezeket a beállításokat máshol kell konfigurálni. A legtöbb esetben ASP.NET Core Identity a Program.cs fájlban van konfigurálva. Nyissa meg a korábban létrehozott webes projektet (az identitástábla sémájának létrehozásához), és tekintse át a Program.cs (vagy Startup.cs) fájlt.

Ez a kód támogatja az EF Core-t és az Identity-et:

// Add services to the container.
var connectionString = builder.Configuration.GetConnectionString("DefaultConnection");
builder.Services.AddDbContext<ApplicationDbContext>(options =>
    options.UseSqlServer(connectionString));

if (builder.Environment.IsDevelopment())
{
    builder.Services.AddDatabaseDeveloperPageExceptionFilter();
}

builder.Services.AddDefaultIdentity<IdentityUser>(options =>
    options.SignIn.RequireConfirmedAccount = true)
    .AddEntityFrameworkStores<ApplicationDbContext>();

A AddDefaultIdentity bővítménymetódus az identitás alapértelmezett és a keretrendszer ApplicationDbContext típusának használatára IdentityUser való konfigurálására szolgál. Ha egyénit IdentityUserhasznál, itt mindenképpen adja meg annak típusát. Ha ezek a bővítménymetelyek nem működnek az alkalmazásban, ellenőrizze, hogy rendelkezik-e a megfelelő using irányelvekkel, és hogy rendelkezik-e a szükséges NuGet-csomaghivatkozásokkal. A projektnek például a hivatkozott csomagok és Microsoft.AspNetCore.Identity.EntityFrameworkCore csomagok Microsoft.AspNetCore.Identity.UI valamelyik verziójával kell rendelkeznie.

A Program.cs is látnia kell a helyhez szükséges köztes szoftvereket. Pontosabban, UseAuthentication és UseAuthorization be kell állítani, és a megfelelő helyen.

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseMigrationsEndPoint();
}
else
{
    app.UseExceptionHandler("/Error");
    // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
    app.UseHsts();
}

app.UseHttpsRedirection();

app.UseStaticFiles();

app.UseRouting();

app.UseAuthentication();
app.UseAuthorization();

//app.MapControllers();
app.MapBlazorHub();
app.MapFallbackToPage("/_Host");

ASP.NET Identitás nem konfigurál névtelen vagy szerepköralapú hozzáférést Program.cs helyekhez. Minden helyspecifikus engedélyezési konfigurációs adatot át kell telepítenie a ASP.NET Core szűrőire. Jegyezze fel, hogy mely mappák és lapok igényelnek ilyen frissítéseket. Ezeket a módosításokat a következő szakaszban fogja végrehajtani.

Az egyes lapok frissítése ASP.NET Core Identity-absztrakciók használatára

Ha a ASP.NET Web Forms-alkalmazásban web.config bizonyos lapokhoz vagy mappákhoz való hozzáférést megtagadó beállításokat adott meg névtelen felhasználók számára, ezeket a módosításokat az [Authorize] attribútum ilyen lapokhoz való hozzáadásával migrálhatja:

@attribute [Authorize]

Ha továbbá megtagadta volna a hozzáférést, kivéve azokat a felhasználókat, akik egy adott szerepkörhöz tartoznak, hasonlóképpen migrálná ezt a viselkedést egy szerepkört meghatározó attribútum hozzáadásával:

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

Az [Authorize] attribútum csak az útválasztón keresztül @page elért összetevőkön Blazor működik. Az attribútum nem működik a gyermekösszetevőkkel, amelyeket inkább használnia AuthorizeViewkell.

Ha az oldaljelölésen belül logikával rendelkezik annak meghatározásához, hogy egy adott felhasználó megjelenít-e valamilyen kódot, ezt lecserélheti az AuthorizeView összetevőre. Az AuthorizeView összetevő szelektíven jeleníti meg a felhasználói felületet attól függően, hogy a felhasználó jogosult-e annak megtekintésére. Emellett egy olyan változót context is elérhetővé tesz, amely a felhasználói adatok eléréséhez használható.

<AuthorizeView>
    <Authorized>
        <h1>Hello, @context.User.Identity.Name!</h1>
        <p>You can only see this content if you are authenticated.</p>
    </Authorized>
    <NotAuthorized>
        <h1>Authentication Failure!</h1>
        <p>You are not signed in.</p>
    </NotAuthorized>
</AuthorizeView>

A hitelesítési állapotot az eljáráslogikán belül úgy érheti el, hogy egy attribútummal Task<AuthenticationState konfigurált felhasználóhoz [CascadingParameter] fér hozzá. Ez a konfiguráció hozzáférést biztosít a felhasználóhoz, így megállapíthatja, hogy hitelesítve vannak-e, és hogy egy adott szerepkörhöz tartoznak-e. Ha egy szabályzatot eljárási szempontból kell kiértékelnie, beszúrhat egy példányt IAuthorizationService , és meghívhatja a metódust AuthorizeAsync rajta. Az alábbi mintakód bemutatja, hogyan kérhet le felhasználói adatokat, és hogyan engedélyezheti egy jogosult felhasználónak a content-editor szabályzat által korlátozott feladat végrehajtását.

@using Microsoft.AspNetCore.Authorization
@inject IAuthorizationService AuthorizationService

<button @onclick="@DoSomething">Do something important</button>

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

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

        if (user.Identity.IsAuthenticated)
        {
            // Perform an action only available to authenticated (signed-in) users.
        }

        if (user.IsInRole("admin"))
        {
            // Perform an action only available to users in the 'admin' role.
        }

        if ((await AuthorizationService.AuthorizeAsync(user, "content-editor"))
            .Succeeded)
        {
            // Perform an action only available to users satisfying the
            // 'content-editor' policy.
        }
    }
}

Az AuthenticationState elsőt kaszkádolt értékként kell beállítani, mielőtt egy ilyen kaszkádolt paraméterhez lehetne kötni. Ez általában az CascadingAuthenticationState összetevő használatával történik. Ez a konfiguráció általában a következő helyen App.razortörténik:

<CascadingAuthenticationState>
    <Router AppAssembly="@typeof(Program).Assembly">
        <Found Context="routeData">
            <AuthorizeRouteView RouteData="@routeData"
                DefaultLayout="@typeof(MainLayout)" />
        </Found>
        <NotFound>
            <LayoutView Layout="@typeof(MainLayout)">
                <p>Sorry, there's nothing at this address.</p>
            </LayoutView>
        </NotFound>
    </Router>
</CascadingAuthenticationState>

Összegzés

Blazor Ugyanazt a biztonsági modellt használja, mint ASP.NET Core, amely ASP.NET Core Identity. Az univerzális szolgáltatókról az ASP.NET Core Identityre való migrálás viszonylag egyszerű, feltételezve, hogy az eredeti adatséma nem alkalmazott túl sok testreszabást. Az adatok migrálása után az alkalmazások hitelesítésével Blazor és engedélyezésével végzett munka jól dokumentált, konfigurálható és programozott támogatást nyújt a legtöbb biztonsági követelményhez.

Hivatkozások

• Az identitás bemutatása a ASP.NET Core-on
• Migrálás ASP.NET tagsági hitelesítésről ASP.NET Core 2.0-identitásra
• Hitelesítés és identitás áttelepítése a ASP.NET Core-ba
• ASP.NET Alapvető Blazor hitelesítés és engedélyezés

Előzőkövetkező