Zabezpieczenia: Uwierzytelnianie i autoryzacja w formularzach internetowych ASP.NET i Blazor

Napiwek

Ta zawartość jest fragmentem książki eBook Blazor dla deweloperów formularzy internetowych platformy ASP NET dla platformy Azure, dostępnym na platformie .NET Docs lub jako bezpłatny plik PDF do pobrania, który można odczytać w trybie offline.

Pobierz plik PDF

Migracja z aplikacji ASP.NET Web Forms do Blazor prawie na pewno będzie wymagać aktualizacji sposobu uwierzytelniania i autoryzacji, przy założeniu, że aplikacja skonfigurowała uwierzytelnianie. W tym rozdziale opisano sposób migrowania z modelu uniwersalnego dostawcy formularzy internetowych ASP.NET Web Forms (dla członkostwa, ról i profilów użytkowników) oraz sposobu pracy z tożsamością podstawową ASP.NET z Blazor aplikacji. Chociaż w tym rozdziale omówiono ogólne kroki i zagadnienia, szczegółowe kroki i skrypty można znaleźć w dokumentacji referencyjnej.

ASP.NET dostawców uniwersalnych

Od ASP.NET 2.0 platforma ASP.NET Web Forms obsługuje model dostawcy dla różnych funkcji, w tym członkostwa. Dostawca członkostwa uniwersalnego wraz z opcjonalnym dostawcą ról jest często wdrażany z aplikacjami ASP.NET Web Forms. Oferuje ona niezawodny i bezpieczny sposób zarządzania uwierzytelnianiem i autoryzacją, która nadal działa dobrze dzisiaj. Najnowsza oferta tych dostawców uniwersalnych jest dostępna jako pakiet NuGet Microsoft.AspNet.Providers.

Dostawcy uniwersalni współpracują ze schematem bazy danych SQL, który zawiera tabele, takie jak aspnet_Applications, aspnet_Membership, aspnet_Rolesi aspnet_Users. Po skonfigurowaniu za pomocą polecenia aspnet_regsql.exe dostawcy instalują tabele i procedury składowane, które udostępniają wszystkie niezbędne zapytania i polecenia do pracy z danymi bazowymi. Schemat bazy danych i te procedury składowane nie są zgodne z nowszymi systemami tożsamości ASP.NET i ASP.NET Core Identity, dlatego istniejące dane muszą zostać zmigrowane do nowego systemu. Rysunek 1 przedstawia przykładowy schemat tabeli skonfigurowany dla dostawców uniwersalnych.

Dostawca uniwersalny obsługuje użytkowników, członkostwo, role i profile. Użytkownicy są przypisywani globalnie unikatowe identyfikatory i podstawowe informacje, takie jak userId, userName itp., są przechowywane w aspnet_Users tabeli. Informacje o uwierzytelnianiu, takie jak hasło, format hasła, sól hasła, liczniki blokady i szczegóły itp., są przechowywane w aspnet_Membership tabeli. Role składają się po prostu z nazw i unikatowych identyfikatorów, które są przypisywane do użytkowników za pośrednictwem aspnet_UsersInRoles tabeli skojarzeń, zapewniając relację wiele do wielu.

Jeśli istniejący system używa ról oprócz członkostwa, musisz przeprowadzić migrację kont użytkowników, skojarzonych haseł, ról i członkostwa roli w ASP.NET Core Identity. Najprawdopodobniej konieczne będzie również zaktualizowanie kodu, w którym obecnie przeprowadzasz kontrole ról przy użyciu instrukcji if, aby zamiast tego korzystać z deklaratywnych filtrów, atrybutów i/lub pomocników tagów. Bardziej szczegółowo omówimy zagadnienia dotyczące migracji na końcu tego rozdziału.

Konfiguracja autoryzacji w formularzach sieci Web

Aby skonfigurować autoryzowany dostęp do niektórych stron w aplikacji ASP.NET Web Forms, zazwyczaj określa się, że niektóre strony lub foldery są niedostępne dla użytkowników anonimowych. Ta konfiguracja jest wykonywana w pliku web.config:

<?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>

Sekcja authentication konfiguracji konfiguruje uwierzytelnianie formularzy dla aplikacji. Sekcja authorization służy do nie zezwalania użytkownikom anonimowym na całą aplikację. Można jednak zapewnić bardziej szczegółowe reguły autoryzacji dla poszczególnych lokalizacji, a także zastosować kontrole autoryzacji oparte na rolach.

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

Powyższa konfiguracja, w połączeniu z pierwszym, umożliwia anonimowym użytkownikom dostęp do strony logowania, przesłaniając ograniczenie całej witryny dla nieuwierzytelnionego użytkownika.

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

Powyższa konfiguracja, w połączeniu z innymi, ogranicza dostęp do /admin folderu i wszystkich zasobów w nim do członków roli "Administratorzy". To ograniczenie można również zastosować, umieszczając oddzielny web.config plik w folderze /admin głównym folderu.

Kod autoryzacji w formularzach sieci Web

Oprócz konfigurowania dostępu przy użyciu programu web.configmożna również programowo skonfigurować dostęp i zachowanie w aplikacji Web Forms. Na przykład można ograniczyć możliwość wykonywania określonych operacji lub wyświetlania określonych danych na podstawie roli użytkownika.

Ten kod może być używany zarówno w logice kodu, jak i w samej stronie:

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

Oprócz sprawdzania członkostwa w rolach użytkownika można również określić, czy są uwierzytelnione (choć często lepiej jest to zrobić przy użyciu konfiguracji opartej na lokalizacji opisanej powyżej). Poniżej przedstawiono przykład tego podejścia.

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;
    }
}

W powyższym kodzie kontrola dostępu oparta na rolach (RBAC) służy do określania, czy niektóre elementy strony, takie jak SecretPanel, są widoczne na podstawie roli bieżącego użytkownika.

Zazwyczaj ASP.NET aplikacje Web Forms konfigurują zabezpieczenia w web.config pliku, a następnie dodają dodatkowe kontrole, w razie potrzeby na .aspx stronach i powiązanych .aspx.cs plikach kodu. Większość aplikacji korzysta z dostawcy członkostwa uniwersalnego, często z dodatkowym dostawcą ról.

tożsamość podstawowa ASP.NET

Mimo że nadal zadanie związane z uwierzytelnianiem i autoryzacją, ASP.NET Core Identity używa innego zestawu abstrakcji i założeń w porównaniu z dostawcami uniwersalnymi. Na przykład nowy model tożsamości obsługuje uwierzytelnianie innych firm, umożliwiając użytkownikom uwierzytelnianie przy użyciu konta mediów społecznościowych lub innego zaufanego dostawcy uwierzytelniania. ASP.NET Core Identity obsługuje interfejs użytkownika dla często potrzebnych stron, takich jak logowanie, wylogowywanie i rejestrowanie. Wykorzystuje platformę EF Core do uzyskiwania dostępu do danych i używa migracji platformy EF Core do generowania niezbędnego schematu wymaganego do obsługi modelu danych. To wprowadzenie do usługi Identity on ASP.NET Core zawiera dobre omówienie elementów zawartych w ASP.NET Core Identity i rozpoczynanie pracy z nią. Jeśli jeszcze nie skonfigurowaliśmy ASP.NET Core Identity w aplikacji i jej bazie danych, pomoże Ci rozpocząć pracę.

Role, oświadczenia i zasady

Zarówno dostawcy uniwersalni, jak i ASP.NET Core Identity obsługują koncepcję ról. Role można tworzyć dla użytkowników i przypisywać użytkowników do ról. Użytkownicy mogą należeć do dowolnej liczby ról i można zweryfikować członkostwo w roli w ramach implementacji autoryzacji.

Oprócz ról tożsamość ASP.NET Core obsługuje koncepcje oświadczeń i zasad. Rola powinna w szczególności odpowiadać zestawowi zasobów, do których użytkownik powinien mieć dostęp, ale oświadczenie jest po prostu częścią tożsamości użytkownika. Oświadczenie jest parą wartości nazwy, która reprezentuje temat, a nie to, co podmiot może zrobić.

Istnieje możliwość bezpośredniego sprawdzenia oświadczeń użytkownika i określenia na podstawie tych wartości, czy użytkownik powinien mieć dostęp do zasobu. Jednak takie kontrole są często powtarzalne i rozproszone w całym systemie. Lepszym podejściem jest zdefiniowanie zasad.

Zasady autoryzacji składają się z co najmniej jednego wymagania. Zasady są rejestrowane w ramach konfiguracji usługi autoryzacji w ConfigureServices metodzie Startup.cs. Na przykład poniższy fragment kodu konfiguruje zasady o nazwie "CanadiansOnly", która ma wymaganie, aby użytkownik miał oświadczenie Country z wartością "Kanada".

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

Więcej informacji na temat tworzenia zasad niestandardowych można dowiedzieć się w dokumentacji.

Niezależnie od tego, czy używasz zasad, czy ról, możesz określić, że określona strona w Blazor aplikacji wymaga tej roli lub zasad z atrybutem [Authorize] zastosowanym w @attribute dyrektywie .

Wymaganie roli:

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

Wymaganie spełnienia zasad:

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

Jeśli potrzebujesz dostępu do stanu uwierzytelniania użytkownika, ról lub oświadczeń w kodzie, istnieją dwa podstawowe sposoby osiągnięcia tej funkcji. Pierwszy to odbieranie stanu uwierzytelniania jako parametr kaskadowy. Drugi to uzyskiwanie dostępu do stanu przy użyciu wprowadzonego AuthenticationStateProviderelementu . Szczegółowe informacje o poszczególnych tych podejściach opisano w Blazor dokumentacji zabezpieczeń.

Poniższy kod przedstawia sposób odbierania parametru AuthenticationState jako parametru kaskadowego:

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

Za pomocą tego parametru możesz pobrać użytkownika przy użyciu tego kodu:

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

Poniższy kod pokazuje, jak wstrzyknąć element AuthenticationStateProvider:

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

Za pomocą dostawcy możesz uzyskać dostęp do użytkownika przy użyciu następującego kodu:

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

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

Uwaga: AuthorizeView Składnik, omówiony w dalszej części tego rozdziału, zapewnia deklaratywny sposób kontrolowania tego, co użytkownik widzi na stronie lub składniku.

Aby pracować z użytkownikami i oświadczeniami (w Blazor aplikacjach serwera), może być również konieczne wstrzyknąć UserManager<T> (domyślnie IdentityUser ), którego można użyć do wyliczania i modyfikowania oświadczeń dla użytkownika. Najpierw wstrzyknąć typ i przypisać go do właściwości:

@inject UserManager<IdentityUser> MyUserManager

Następnie użyj go do pracy z oświadczeniami użytkownika. W poniższym przykładzie pokazano, jak dodać i utrwały oświadczenie dla użytkownika:

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"));
    }
}

Jeśli musisz pracować z rolami, postępuj zgodnie z tym samym podejściem. Aby wyświetlić listę ról i zarządzać nimi, może być konieczne wstrzyknięcie RoleManager<T> elementu (użyj IdentityRole dla typu domyślnego).

Uwaga: w Blazor projektach zestawu WebAssembly należy udostępnić interfejsy API serwera do wykonywania tych operacji (zamiast używania UserManager<T> lub RoleManager<T> bezpośredniego). Blazor Aplikacja kliencka zestawu WebAssembly zarządza oświadczeniami i/lub rolami przez bezpieczne wywoływanie punktów końcowych interfejsu API uwidocznionych w tym celu.

Przewodnik migracji

Migracja z ASP.NET web forms i dostawców uniwersalnych do usługi ASP.NET Core Identity wymaga wykonania kilku kroków:

1. Tworzenie schematu bazy danych ASP.NET Core Identity w docelowej bazie danych
2. Migrowanie danych ze schematu dostawcy uniwersalnego do schematu tożsamości podstawowej ASP.NET
3. Migrowanie konfiguracji z oprogramowania pośredniczącego web.config i usług, zazwyczaj w Program.cs (lub Startup klasie)
4. Zaktualizuj poszczególne strony przy użyciu kontrolek i warunkowych, aby używać pomocników tagów i nowych interfejsów API tożsamości.

Wszystkie wymienione kroki zostały szczegółowo opisane poniżej.

Tworzenie schematu tożsamości podstawowej ASP.NET

Istnieje kilka sposobów tworzenia niezbędnej struktury tabeli używanej dla ASP.NET Core Identity. Najprostszym sposobem jest utworzenie nowej aplikacji internetowej ASP.NET Core. Wybierz pozycję Aplikacja internetowa, a następnie zmień typ uwierzytelniania, aby używać indywidualnych kont.

W wierszu polecenia możesz wykonać to samo, uruchamiając polecenie dotnet new webapp -au Individual. Po utworzeniu aplikacji uruchom ją i zarejestruj w witrynie. Powinna zostać wyzwolna strona podobna do przedstawionej poniżej:

Kliknij przycisk "Zastosuj migracje" i należy utworzyć niezbędne tabele bazy danych. Ponadto pliki migracji powinny być wyświetlane w projekcie, jak pokazano poniżej:

Migrację można uruchomić samodzielnie bez uruchamiania aplikacji internetowej przy użyciu tego narzędzia wiersza polecenia:

dotnet ef database update

Jeśli wolisz uruchomić skrypt, aby zastosować nowy schemat do istniejącej bazy danych, możesz utworzyć skrypty tych migracji z wiersza polecenia. Uruchom to polecenie, aby wygenerować skrypt:

dotnet ef migrations script -o auth.sql

Powyższe polecenie spowoduje utworzenie skryptu SQL w pliku auth.sqlwyjściowym , który można następnie uruchomić względem dowolnej bazy danych. Jeśli masz problemy z uruchamianiem dotnet ef poleceń, upewnij się, że masz zainstalowane narzędzia EF Core w systemie.

Jeśli masz dodatkowe kolumny w tabelach źródłowych, musisz zidentyfikować najlepszą lokalizację tych kolumn w nowym schemacie. Ogólnie rzecz biorąc, kolumny znajdujące się w aspnet_Membership tabeli powinny być mapowane na tabelę AspNetUsers . Kolumny na obiekcie aspnet_Roles powinny być mapowane na AspNetRoles. Wszystkie dodatkowe kolumny w aspnet_UsersInRoles tabeli zostaną dodane do AspNetUserRoles tabeli.

Warto również rozważyć umieszczenie dodatkowych kolumn w osobnych tabelach. Aby przyszłe migracje nie musiały uwzględniać takich dostosowań domyślnego schematu tożsamości.

Migrowanie danych z dostawców uniwersalnych do usługi ASP.NET Core Identity

Po utworzeniu schematu tabeli docelowej następnym krokiem jest migracja rekordów użytkowników i ról do nowego schematu. Pełną listę różnic schematu, w tym kolumny mapowania nowych kolumn, można znaleźć tutaj.

Aby przeprowadzić migrację użytkowników z członkostwa do nowych tabel tożsamości, wykonaj kroki opisane w dokumentacji. Po wykonaniu tych kroków i podanym skrypcie użytkownicy będą musieli zmienić swoje hasło przy następnym zalogowaniu.

Istnieje możliwość migracji haseł użytkowników, ale proces jest znacznie bardziej zaangażowany. Wymaganie od użytkowników zaktualizowania haseł w ramach procesu migracji i zachęcanie ich do korzystania z nowych, unikatowych haseł może zwiększyć ogólne bezpieczeństwo aplikacji.

Migrowanie ustawień zabezpieczeń z pliku web.config do uruchamiania aplikacji

Jak wspomniano powyżej, ASP.NET członkostwa i dostawców ról są konfigurowane w pliku aplikacji web.config . Ponieważ aplikacje ASP.NET Core nie są powiązane z usługami IIS i używają oddzielnego systemu do konfiguracji, te ustawienia muszą być skonfigurowane w innym miejscu. W większości przypadków tożsamość podstawowa ASP.NET jest konfigurowana w pliku Program.cs . Otwórz utworzony wcześniej projekt internetowy (w celu wygenerowania schematu tabeli tożsamości) i przejrzyj jego plik Program.cs (lub Startup.cs).

Ten kod dodaje obsługę platformy EF Core i tożsamości:

// Add services to the container.
var connectionString = builder.Configuration.GetConnectionString("DefaultConnection");
builder.Services.AddDbContext<ApplicationDbContext>(options =>
    options.UseSqlServer(connectionString));
builder.Services.AddDatabaseDeveloperPageExceptionFilter();
builder.Services.AddDefaultIdentity<IdentityUser>(options =>
    options.SignIn.RequireConfirmedAccount = true)
    .AddEntityFrameworkStores<ApplicationDbContext>();

Metoda AddDefaultIdentity rozszerzenia służy do konfigurowania tożsamości do używania wartości domyślnej ApplicationDbContext i typu platformy IdentityUser . Jeśli używasz niestandardowego IdentityUserelementu , pamiętaj, aby określić jego typ tutaj. Jeśli te metody rozszerzenia nie działają w aplikacji, sprawdź, czy masz odpowiednie using dyrektywy i czy masz niezbędne odwołania do pakietu NuGet. Na przykład projekt powinien mieć przywołyną wersję Microsoft.AspNetCore.Identity.EntityFrameworkCore pakietów i Microsoft.AspNetCore.Identity.UI .

Ponadto w Program.cs powinny zostać wyświetlone niezbędne oprogramowanie pośredniczące skonfigurowane dla lokacji. W szczególności należy UseAuthentication skonfigurować i UseAuthorization w odpowiedniej lokalizacji.

// 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 Identity nie konfiguruje dostępu anonimowego ani opartego na rolach do lokalizacji z Program.cs. Należy przeprowadzić migrację wszystkich danych konfiguracji autoryzacji specyficznych dla lokalizacji do filtrów w ASP.NET Core. Zanotuj, które foldery i strony będą wymagały takich aktualizacji. Te zmiany zostaną wprowadzone w następnej sekcji.

Aktualizowanie poszczególnych stron w celu używania abstrakcji ASP.NET Core Identity

W aplikacji ASP.NET Web Forms, jeśli masz web.config ustawienia odmowy dostępu do niektórych stron lub folderów użytkownikom anonimowym, te zmiany zostaną zmigrowane przez dodanie atrybutu [Authorize] do takich stron:

@attribute [Authorize]

Jeśli dodatkowo odmówiono dostępu z wyjątkiem tych użytkowników należących do określonej roli, należy również przeprowadzić migrację tego zachowania przez dodanie atrybutu określającego rolę:

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

Atrybut [Authorize] działa tylko na @page składnikach, które są osiągane za pośrednictwem routera Blazor . Atrybut nie działa z składnikami podrzędnymi, które powinny zamiast tego używać polecenia AuthorizeView.

Jeśli masz logikę w znacznikach strony do określania, czy wyświetlić jakiś kod dla określonego użytkownika, możesz zastąpić go składnikiem AuthorizeView . Składnik AuthorizeView selektywnie wyświetla interfejs użytkownika w zależności od tego, czy użytkownik ma uprawnienia do jego wyświetlania. Uwidacznia również zmienną context , która może służyć do uzyskiwania dostępu do informacji o użytkowniku.

<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>

Dostęp do stanu uwierzytelniania można uzyskać w ramach logiki proceduralnej, przechodząc do użytkownika ze skonfigurowanego Task<AuthenticationState za pomocą atrybutu [CascadingParameter] . Ta konfiguracja umożliwia uzyskanie dostępu do użytkownika, co pozwala określić, czy są uwierzytelnione, oraz czy należą do określonej roli. Jeśli musisz ocenić zasady proceduralnie, możesz wstrzyknąć wystąpienie IAuthorizationService obiektu i wywołać metodę AuthorizeAsync . Poniższy przykładowy kod pokazuje, jak uzyskać informacje o użytkowniku i zezwolić autoryzowanemu użytkownikowi na wykonywanie zadania ograniczonego content-editor przez zasady.

@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.
        }
    }
}

Najpierw AuthenticationState należy skonfigurować jako wartość kaskadową, zanim będzie można ją powiązać z kaskadowym parametrem, takim jak ten. Zazwyczaj odbywa się to przy użyciu CascadingAuthenticationState składnika . Ta konfiguracja jest zwykle wykonywana w programie App.razor:

<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>

Podsumowanie

Blazor używa tego samego modelu zabezpieczeń co ASP.NET Core, który jest ASP.NET Core Identity. Migracja z dostawców uniwersalnych do ASP.NET tożsamości podstawowej jest stosunkowo prosta, przy założeniu, że nie zastosowano zbyt dużego dostosowania do oryginalnego schematu danych. Po przeprowadzeniu migracji danych praca z uwierzytelnianiem i autoryzacją w Blazor aplikacjach jest dobrze udokumentowana, z możliwością skonfigurowania oraz obsługą programową dla większości wymagań dotyczących zabezpieczeń.

Informacje

• Wprowadzenie do tożsamości w usłudze ASP.NET Core
• Migrowanie z uwierzytelniania członkostwa ASP.NET do tożsamości ASP.NET Core 2.0
• Migrowanie uwierzytelniania i tożsamości do ASP.NET Core
• Uwierzytelnianie i autoryzacja w aplikacjach Blazor na platformie ASP.NET Core

PoprzedniNastępny