Zabezpečení ASP.NET Core aplikace Blazor WebAssembly pomocí Identity Serveru

Tento článek vysvětluje, jak vytvořit hostované Blazor WebAssembly řešení, které používá Identity Server Duende k ověřování uživatelů a volání rozhraní API.

dotnet new blazorwasm -au Individual -ho -o {APP NAME}

Server konfigurace aplikace

V následujících částech jsou popsány dodatky k projektu, pokud je zahrnuta podpora ověřování.

Startup – třída

Třída Startup má následující doplňky.

• V Program.cs:

  • ASP.NET Core Identity:

    builder.Services.AddDbContext<ApplicationDbContext>(options =>
        options.UseSqlite(
            Configuration.GetConnectionString("DefaultConnection")));
    
    builder.Services.AddDefaultIdentity<ApplicationUser>(options => 
            options.SignIn.RequireConfirmedAccount = true)
        .AddEntityFrameworkStores<ApplicationDbContext>();
    

  • IdentityServer s další AddApiAuthorization pomocná metoda, která nastavuje výchozí ASP.NET Core konvence na Identity serveru:

    builder.Services.AddIdentityServer()
        .AddApiAuthorization<ApplicationUser, ApplicationDbContext>();
    

  • Ověřování pomocí další pomocné metody, která konfiguruje aplikaci tak, aby ověřoval AddIdentityServerJwt tokeny JWT vytvořené Identity serverem:

    builder.Services.AddAuthentication()
        .AddIdentityServerJwt();
    

• V Program.cs:

  • Middleware Identity Server zpřístupňuje koncové body Připojení (OIDC):

    app.UseIdentityServer();
    

  • Middleware pro ověřování zodpovídá za ověřování přihlašovacích údajů požadavku a nastavení uživatele v kontextu požadavku:

    app.UseAuthentication();
    

  • Autorizační middleware umožňuje funkce autorizace:

    app.UseAuthorization();
    

Azure App Service v Linuxu

Explicitně zadejte vystavitele při nasazování do Azure App Service v Linuxu. Další informace naleznete v tématu Úvod do ověřování pro jedno stránkové aplikace v ASP.NET Core.

AddApiAuthorization

Pomocná AddApiAuthorization metoda konfiguruje Identity server pro ASP.NET Core scénářů. Identity Server je výkonná a rozšiřitelná rozhraní pro řešení problémů se zabezpečením aplikací. IdentityServer zpřístupňuje zbytečnou složitost pro nejběžnější scénáře. V důsledku toho je k dispozici sada konvencí a možností konfigurace, které považujeme za dobrý výchozí bod. Jakmile se vaše potřeby ověřování změní, bude možné plně výkon serveru přizpůsobit ověřování tak, aby Identity vyhovovalo požadavkům aplikace.

Přidání Identity ServeruJwt

Pomocná metoda nakonfiguruje schéma zásad pro aplikaci jako AddIdentityServerJwt výchozí obslužnou rutinu ověřování. Zásada je nakonfigurovaná tak, aby Identity povolla zpracování všech požadavků směrovaných na libovolnou dílčí cestu v Identity adresách /Identity URL. Zpracovává JwtBearerHandler všechny ostatní požadavky. Kromě toho tato metoda:

• Zaregistruje prostředek {APPLICATION NAME}API rozhraní API na server s výchozím Identity oborem {APPLICATION NAME}API .
• Nakonfiguruje middleware tokenů bearer JWT pro ověřování tokenů Identity vydaných serverem pro aplikaci.

WeatherForecastController

V WeatherForecastController ( Controllers/WeatherForecastController.cs ) se [Authorize] atribut použije na třídu . Atribut označuje, že uživatel musí být autorizován na základě výchozích zásad pro přístup k prostředku. Výchozí zásady autorizace jsou nakonfigurované tak, aby se používá výchozí schéma ověřování, které je nastavené pomocí AddIdentityServerJwt . Pomocná metoda se JwtBearerHandler nakonfiguruje jako výchozí obslužná rutina pro požadavky na aplikaci.

ApplicationDbContext

V ApplicationDbContext souboru ( Data/ApplicationDbContext.cs ) se rozšiřuje o schéma pro DbContext ApiAuthorizationDbContext<TUser> Identity Server. ApiAuthorizationDbContext<TUser> je odvozený z IdentityDbContext .

Pokud chcete získat úplnou kontrolu nad schématem databáze, dědte z jedné z dostupných tříd a nakonfigurujte kontext tak, aby zahrnoval Identity DbContext Identity schéma builder.ConfigurePersistedGrantContext(_operationalStoreOptions.Value) voláním v OnModelCreating metodě .

OidcConfigurationController

V OidcConfigurationController ( Controllers/OidcConfigurationController.cs ) je koncový bod klienta zřízen pro obsluhu parametrů OIDC.

Nastavení aplikace

Část v souboru nastavení aplikace ( appsettings.json ) v kořenovém adresáři projektu popisuje seznam IdentityServer nakonfigurovaných klientů. V následujícím příkladu je jeden klient. Název klienta odpovídá názvu aplikace a podle konvence se mapuje na parametr ClientId OAuth. Profil označuje konfigurovaný typ aplikace. Profil se používá interně k řízení konvencí, které zjednodušují proces konfigurace serveru.

"IdentityServer": {
  "Clients": {
    "{APP ASSEMBLY}.Client": {
      "Profile": "IdentityServerSPA"
    }
  }
}

Zástupný {APP ASSEMBLY} symbol je název sestavení aplikace (například BlazorSample.Client ).

Client konfigurace aplikace

Ověřovací balíček

Když se vytvoří aplikace pro použití individuálních uživatelských účtů ( ), aplikace automaticky obdrží odkaz na balíček v souboru projektu Individual Microsoft.AspNetCore.Components.WebAssembly.Authentication aplikace. Balíček poskytuje sadu primitiv, které aplikaci pomáhají ověřovat uživatele a získávat tokeny pro volání chráněných rozhraní API.

Pokud přidáváte ověřování do aplikace, ručně přidejte balíček do souboru projektu aplikace:

<PackageReference 
  Include="Microsoft.AspNetCore.Components.WebAssembly.Authentication" 
  Version="{VERSION}" />

Pro zástupný symbol najdete nejnovější stabilní verzi balíčku, která odpovídá verzi sdílené architektury aplikace, v historii verzí balíčku na {VERSION} NuGet.org.

HttpClient Konfigurace

V systému je nakonfigurovaný pojmenovaný ( ) pro poskytování instancí, které Program.cs HttpClient zahrnují {APP ASSEMBLY}.ServerAPI přístupové tokeny při provádění požadavků HttpClient na rozhraní API serveru:

builder.Services.AddHttpClient("{APP ASSEMBLY}.ServerAPI", 
        client => client.BaseAddress = new Uri(builder.HostEnvironment.BaseAddress))
    .AddHttpMessageHandler<BaseAddressAuthorizationMessageHandler>();

builder.Services.AddScoped(sp => sp.GetRequiredService<IHttpClientFactory>()
    .CreateClient("{APP ASSEMBLY}.ServerAPI"));

Zástupný {APP ASSEMBLY} symbol je název sestavení aplikace (například BlazorSample.Client ).

Podpora autorizace rozhraní API

Podpora ověřování uživatelů je zapojená do kontejneru služby pomocí metody rozšíření poskytované uvnitř Microsoft.AspNetCore.Components.WebAssembly.Authentication balíčku. Tato metoda nastaví služby vyžadované aplikací pro interakci se stávajícím autorizačním systémem.

builder.Services.AddApiAuthorization();

Ve výchozím nastavení se konfigurace aplikace načítá podle konvence z _configuration/{client-id} . Podle konvence je ID klienta nastaveno na název sestavení aplikace. Tuto adresu URL lze změnit tak, aby odkazovat na samostatný koncový bod voláním přetížení s možnostmi.

Soubor importů

Obor Microsoft.AspNetCore.Components.Authorization názvů je k dispozici v celé aplikaci prostřednictvím souboru _Imports.razor :

@using System.Net.Http
@using System.Net.Http.Json
@using Microsoft.AspNetCore.Components.Authorization
@using Microsoft.AspNetCore.Components.Forms
@using Microsoft.AspNetCore.Components.Routing
@using Microsoft.AspNetCore.Components.Web
@using Microsoft.AspNetCore.Components.Web.Virtualization
@using Microsoft.AspNetCore.Components.WebAssembly.Http
@using Microsoft.JSInterop
@using {APPLICATION ASSEMBLY}.Client
@using {APPLICATION ASSEMBLY}.Client.Shared

Indexová stránka

Stránka Index wwwroot/index.html (Index) obsahuje skript, který definuje v AuthenticationService JavaScriptu. AuthenticationService zpracovává podrobnosti nízké úrovně protokolu OIDC. Aplikace interně volá metody definované ve skriptu k provedení ověřovacích operací.

<script src="_content/Microsoft.AspNetCore.Components.WebAssembly.Authentication/
    AuthenticationService.js"></script>

Komponenta aplikace

AppSoučást ( App.razor ) je podobná App komponentě, kterou najdete v Blazor Server aplikacích:

• Komponenta spravuje vystavení CascadingAuthenticationState AuthenticationState do zbytku aplikace.
• AuthorizeRouteViewKomponenta zajistí, že aktuální uživatel má oprávnění pro přístup k dané stránce nebo jinak vykreslí RedirectToLogin součást.
• RedirectToLoginKomponenta spravuje přesměrování neautorizovaných uživatelů na přihlašovací stránku.

v důsledku změn v rozhraní napříč verzemi ASP.NET Core se Razor App App.razor v této části nezobrazí značka pro komponentu (). Chcete-li zkontrolovat označení komponenty pro danou verzi, použijte některý z následujících přístupů:

• vytvořte aplikaci zřízenou pro ověřování z výchozí Blazor WebAssembly šablony projektu pro verzi ASP.NET Core, kterou chcete použít. Zkontrolujte App součást ( App.razor ) ve vygenerované aplikaci.

• Zkontrolujte App součást ( App.razor ) v referenčním zdroji.

  Poznámka

  dokumentace odkazuje na zdrojový odkaz na ASP.NET Core načtení main větve úložiště, která představuje aktuální vývoj jednotky produktu pro další verzi ASP.NET Core. Pokud chcete vybrat větev pro jinou verzi, vyberte ji pomocí rozevíracího seznamu větve přepínače nebo značky . vyberte například release/5.0 větev pro verzi ASP.NET Core 5,0.

Komponenta RedirectToLogin

RedirectToLoginSoučást ( Shared/RedirectToLogin.razor ):

• Spravuje přesměrování neautorizovaných uživatelů na přihlašovací stránku.
• Zachová aktuální adresu URL, ke které se uživatel pokouší získat přístup, aby se mohla vrátit na tuto stránku, pokud je ověření úspěšné.

@inject NavigationManager Navigation
@using Microsoft.AspNetCore.Components.WebAssembly.Authentication
@code {
    protected override void OnInitialized()
    {
        Navigation.NavigateTo(
            $"authentication/login?returnUrl={Uri.EscapeDataString(Navigation.Uri)}");
    }
}

Komponenta LoginDisplay

Komponenta LoginDisplay ( Shared/LoginDisplay.razor ) se vykreslí v komponentě ( ) a spravuje MainLayout následující Shared/MainLayout.razor chování:

• Pro ověřené uživatele:
  • Zobrazí aktuální uživatelské jméno.
  • Nabízí odkaz na stránku profilu uživatele v ASP.NET Core Identity .
  • Nabízí tlačítko pro odhlášení z aplikace.
• Anonymní uživatelé:
  • Nabízí možnost registrace.
  • Nabízí možnost přihlášení.

@using Microsoft.AspNetCore.Components.Authorization
@using Microsoft.AspNetCore.Components.WebAssembly.Authentication
@inject NavigationManager Navigation
@inject SignOutSessionStateManager SignOutManager

<AuthorizeView>
    <Authorized>
        <a href="authentication/profile">Hello, @context.User.Identity.Name!</a>
        <button class="nav-link btn btn-link" @onclick="BeginSignOut">
            Log out
        </button>
    </Authorized>
    <NotAuthorized>
        <a href="authentication/register">Register</a>
        <a href="authentication/login">Log in</a>
    </NotAuthorized>
</AuthorizeView>

@code {
    private async Task BeginSignOut(MouseEventArgs args)
    {
        await SignOutManager.SetSignOutState();
        Navigation.NavigateTo("authentication/logout");
    }
}

Ověřovací komponenta

Stránka vytvořená komponentou ( ) definuje trasy vyžadované Authentication pro zpracování různých fází Pages/Authentication.razor ověřování.

RemoteAuthenticatorViewKomponenta:

• Je poskytován Microsoft.AspNetCore.Components.WebAssembly.Authentication balíčkem .
• Spravuje provádění příslušných akcí v každé fázi ověřování.

@page "/authentication/{action}"
@using Microsoft.AspNetCore.Components.WebAssembly.Authentication

<RemoteAuthenticatorView Action="@Action" />

@code {
    [Parameter]
    public string Action { get; set; }
}

Komponenta FetchData

Tato FetchData součást ukazuje, jak:

• Zřízení přístupového tokenu
• Pomocí přístupového tokenu v serverové aplikaci zavolejte chráněné rozhraní API prostředků.

Tato @attribute [Authorize] direktiva indikuje Blazor WebAssembly autorizačnímu systému, že uživatel musí být autorizovaný, aby mohl navštívit tuto součást. Přítomnost atributu v Client aplikaci nebrání volání rozhraní API na serveru bez správných přihlašovacích údajů. Server [Authorize] K jejich správné ochraně musí aplikace také použít příslušné koncové body.

IAccessTokenProvider.RequestAccessToken postará o vyžadování přístupového tokenu, který se dá přidat do žádosti o volání rozhraní API. Pokud je token uložen v mezipaměti nebo služba může zřídit nový přístupový token bez zásahu uživatele, požadavek na token je úspěšný. V opačném případě požadavek tokenu selže s objektem AccessTokenNotAvailableException , který je zachycen v try-catch příkazu.

Aby bylo možné získat skutečný token, který se má zahrnout do žádosti, musí aplikace ověřit, jestli žádost proběhla úspěšně voláním tokenResult.TryGetToken(out var token) .

Pokud byl požadavek úspěšný, je proměnná tokenu naplněná přístupovým tokenem. AccessToken.ValueVlastnost tokenu zpřístupňuje řetězec literálu, který má být zahrnut v Authorization hlavičce požadavku.

Pokud se žádost nezdařila, protože se token nepodařilo zřídit bez zásahu uživatele, výsledek tokenu obsahuje adresu URL pro přesměrování. Když přejdete na tuto adresu URL, uživatel přejde na přihlašovací stránku a vrátí se zpátky na aktuální stránku po úspěšném ověření.

@page "/fetchdata"
@using Microsoft.AspNetCore.Authorization
@using Microsoft.AspNetCore.Components.WebAssembly.Authentication
@using {APP NAMESPACE}.Shared
@attribute [Authorize]
@inject HttpClient Http

...

@code {
    private WeatherForecast[] forecasts;

    protected override async Task OnInitializedAsync()
    {
        try
        {
            forecasts = await Http.GetFromJsonAsync<WeatherForecast[]>("WeatherForecast");
        }
        catch (AccessTokenNotAvailableException exception)
        {
            exception.Redirect();
        }
    }
}

Spuštění aplikace

Spusťte aplikaci z projektu Server. Při použití Visual Studio:

• V rozevíracím seznamu Projekty po spuštění na panelu nástrojů nastavte aplikaci Server API a vyberte tlačítko Spustit.
• Vyberte projekt Server v Průzkumník řešení a na panelu nástrojů vyberte tlačítko Spustit nebo spusťte aplikaci z nabídky Ladit.

Název a deklarace identity role s autorizací rozhraní API

Vlastní uživatelská továrna

V aplikaci Client vytvořte vlastní uživatelskou továrnu. Identity Server odešle několik rolí jako pole JSON v jedné role deklaraci identity. Jedna role se odesílá jako řetězcová hodnota v deklaraci identity. Továrna vytvoří role jednotlivou deklaraci identity pro každou z rolí uživatele.

CustomUserFactory.cs:

using System.Linq;
using System.Security.Claims;
using System.Text.Json;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Components.WebAssembly.Authentication;
using Microsoft.AspNetCore.Components.WebAssembly.Authentication.Internal;

public class CustomUserFactory
    : AccountClaimsPrincipalFactory<RemoteUserAccount>
{
    public CustomUserFactory(IAccessTokenProviderAccessor accessor)
        : base(accessor)
    {
    }

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

        if (user.Identity.IsAuthenticated)
        {
            var identity = (ClaimsIdentity)user.Identity;
            var roleClaims = identity.FindAll(identity.RoleClaimType).ToArray();

            if (roleClaims.Any())
            {
                foreach (var existingClaim in roleClaims)
                {
                    identity.RemoveClaim(existingClaim);
                }

                var rolesElem = account.AdditionalProperties[identity.RoleClaimType];

                if (rolesElem is JsonElement roles)
                {
                    if (roles.ValueKind == JsonValueKind.Array)
                    {
                        foreach (var role in roles.EnumerateArray())
                        {
                            identity.AddClaim(new Claim(options.RoleClaim, role.GetString()));
                        }
                    }
                    else
                    {
                        identity.AddClaim(new Claim(options.RoleClaim, roles.GetString()));
                    }
                }
            }
        }

        return user;
    }
}

V aplikaci Client zaregistrujte továrnu v Program.cs :

builder.Services.AddApiAuthorization()
    .AddAccountClaimsPrincipalFactory<CustomUserFactory>();

V aplikaci Server zavolejte tvůrce, AddRoles který přidá služby související s Identity rolemi:

using Microsoft.AspNetCore.Identity;

...

services.AddDefaultIdentity<ApplicationUser>(options => 
    options.SignIn.RequireConfirmedAccount = true)
    .AddRoles<IdentityRole>()
    .AddEntityFrameworkStores<ApplicationDbContext>();

Konfigurace Identity serveru

Použijte jeden z následujících přístupů:

• Možnosti autorizace rozhraní API
• Profilová služba

Možnosti autorizace rozhraní API

V Server aplikaci:

• Nakonfigurujte Identity Server tak, aby se deklarace identity a name vložily do role tokenu ID a přístupového tokenu.
• Zabraňte výchozímu mapování rolí v obslužné rutině tokenu JWT.

using System.IdentityModel.Tokens.Jwt;
using System.Linq;

...

services.AddIdentityServer()
    .AddApiAuthorization<ApplicationUser, ApplicationDbContext>(options => {
        options.IdentityResources["openid"].UserClaims.Add("name");
        options.ApiResources.Single().UserClaims.Add("name");
        options.IdentityResources["openid"].UserClaims.Add("role");
        options.ApiResources.Single().UserClaims.Add("role");
    });

JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Remove("role");

Profilová služba

V Server aplikaci vytvořte ProfileService implementaci.

ProfileService.cs:

using IdentityModel;
using Duende.IdentityServer.Models;
using Duende.IdentityServer.Services;
using System.Threading.Tasks;

public class ProfileService : IProfileService
{
    public ProfileService()
    {
    }

    public async Task GetProfileDataAsync(ProfileDataRequestContext context)
    {
        var nameClaim = context.Subject.FindAll(JwtClaimTypes.Name);
        context.IssuedClaims.AddRange(nameClaim);

        var roleClaims = context.Subject.FindAll(JwtClaimTypes.Role);
        context.IssuedClaims.AddRange(roleClaims);

        await Task.CompletedTask;
    }

    public async Task IsActiveAsync(IsActiveContext context)
    {
        await Task.CompletedTask;
    }
}

V aplikaci Server zaregistrujte službu profilu v Program.cs :

using Duende.IdentityServer.Services;

...

builder.Services.AddTransient<IProfileService, ProfileService>();

JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Remove("role");

Použití autorizačních mechanismů

V aplikaci jsou v tuto chvíli funkční Client přístupy k autorizaci komponent. Kterýkoli z autorizačních mechanismů v komponentách může k autorizaci uživatele použít roli:

• AuthorizeView component (příklad: <AuthorizeView Roles="admin"> )

• [Authorize] attribute – direktiva ( AuthorizeAttribute ) (Příklad: @attribute [Authorize(Roles = "admin")] )

• Procedurální logika (příklad: if (user.IsInRole("admin")) { ... } )

  Podporuje se více testů rolí:

  if (user.IsInRole("admin") && user.IsInRole("developer"))
  {
      ...
  }
  

User.Identity.Name se v aplikaci naplní uživatelským jménem uživatele, což je obvykle Client přihlašovací e-mailová adresa.

UserManager a SignInManager

Nastavte typ deklarace identity identifikátoru uživatele, když serverová aplikace vyžaduje:

• UserManager<TUser> nebo SignInManager<TUser> v koncovém bodu rozhraní API.
• IdentityUser podrobnosti, jako je jméno uživatele, e-mailová adresa nebo koncový čas uzamčení.

In Program.cs pro ASP.NET Core 6.0 nebo novější:

using System.Security.Claims;

...

builder.Services.Configure<IdentityOptions>(options => 
    options.ClaimsIdentity.UserIdClaimType = ClaimTypes.NameIdentifier);

Ve Startup.ConfigureServices verzi ASP.NET Core starší než 6.0:

using System.Security.Claims;

...

services.Configure<IdentityOptions>(options => 
    options.ClaimsIdentity.UserIdClaimType = ClaimTypes.NameIdentifier);

Následující kód WeatherForecastController UserName protokoluje, kdy Get je volána metoda :

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Identity;
using Microsoft.Extensions.Logging;
using {APP NAMESPACE}.Server.Models;
using {APP NAMESPACE}.Shared;

namespace {APP NAMESPACE}.Server.Controllers
{
    [Authorize]
    [ApiController]
    [Route("[controller]")]
    public class WeatherForecastController : ControllerBase
    {
        private readonly UserManager<ApplicationUser> userManager;

        private static readonly string[] Summaries = new[]
        {
            "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", 
            "Balmy", "Hot", "Sweltering", "Scorching"
        };

        private readonly ILogger<WeatherForecastController> logger;

        public WeatherForecastController(ILogger<WeatherForecastController> logger, 
            UserManager<ApplicationUser> userManager)
        {
            this.logger = logger;
            this.userManager = userManager;
        }

        [HttpGet]
        public async Task<IEnumerable<WeatherForecast>> Get()
        {
            var rng = new Random();

            var user = await userManager.GetUserAsync(User);

            if (user != null)
            {
                logger.LogInformation($"User.Identity.Name: {user.UserName}");
            }

            return Enumerable.Range(1, 5).Select(index => new WeatherForecast
            {
                Date = DateTime.Now.AddDays(index),
                TemperatureC = rng.Next(-20, 55),
                Summary = Summaries[rng.Next(Summaries.Length)]
            })
            .ToArray();
        }
    }
}

Hostování v Azure App Service s vlastní doménou a certifikátem

Následující pokyny vysvětlují:

• Postup nasazení hostované Blazor WebAssembly aplikace se Identity Serverem Azure App Service s vlastní doménou
• Jak vytvořit a používat certifikát TLS pro komunikaci protokolu HTTPS s prohlížeči. Přestože se pokyny zaměřují na používání certifikátu s vlastní doménou, pokyny platí stejně pro použití výchozí domény Azure Apps, například contoso.azurewebsites.net .

V tomto scénáři hostování nepoužívejte stejný certifikát pro podpisový Identity klíč tokenu serveru a zabezpečenou komunikaci https webu s prohlížeči:

• Použití různých certifikátů pro tyto dva požadavky je dobrým postupem zabezpečení, protože izoluje privátní klíče pro každý účel.
• Certifikáty TLS pro komunikaci s prohlížeči se spravují nezávisle, aniž by to ovlivnilo podepisování Identity tokenů serveru.
• Když Azure Key Vault do aplikace App Service certifikát pro vlastní vazbu domény, server nemůže získat stejný certifikát od Azure Key Vault pro podepisování Identity tokenů. Přestože je možné nakonfigurovat server tak, aby ve fyzické cestě používá stejný certifikát TLS, umístění certifikátů zabezpečení do správy zdrojového kódu je špatným postupem a ve většině scénářů byste se měli Identity vyhnout.

V následujících pokynech se certifikát podepsaný svým držitelem vytvoří v Azure Key Vault výhradně pro podepisování Identity tokenu serveru. Konfigurace Identity serveru používá certifikát trezoru klíčů prostřednictvím úložiště certifikátů CurrentUser > My aplikace. Ostatní certifikáty používané pro provoz HTTPS s vlastními doménami se vytvářejí a konfigurují odděleně od Identity podpisového certifikátu serveru.

Konfigurace aplikace, Azure App Service a Azure Key Vault k hostování s vlastní doménou a HTTPS:

1. Vytvořte App Service plán s úrovní plánu nebo Basic B1 vyšší. App Service používání vlastních Basic B1 domén vyžaduje úroveň služby nebo vyšší.

2. Vytvořte certifikát PFX pro zabezpečenou komunikaci prohlížeče webu (protokol HTTPS) se společným názvem plně kvalifikovaného názvu domény (FQDN) webu, který řídí vaše organizace (například www.contoso.com ). Vytvořte certifikát pomocí:

   • Použití klíče
     • Ověření digitálního podpisu ( digitalSignature )
     • Šifrování klíče ( keyEncipherment )
   • Použití rozšířeného nebo rozšířeného klíče
     • Ověřování klientů (1.3.6.1.5.5.7.3.2)
     • Ověřování serveru (1.3.6.1.5.5.7.3.1)

   K vytvoření certifikátu použijte jeden z následujících přístupů nebo jiný vhodný nástroj nebo online službu:

   • Azure Key Vault
   • MakeCert na Windows
   • Openssl

   Poznamenejte si heslo, které se později použije k importu certifikátu do Azure Key Vault.

   Další informace o certifikátech Azure Key Vault v tématu Azure Key Vault: Certifikáty.

3. Vytvořte nový trezor Azure Key Vault nebo použijte existující trezor klíčů ve vašem předplatném Azure.

4. V oblasti Certifikáty trezoru klíčů naimportujte certifikát lokality PFX. Zaznamente si kryptografický otisk certifikátu, který se použije v konfiguraci aplikace později.

5. V Azure Key Vault vytvořte nový certifikát podepsaný svým držitelem pro podepisování Identity tokenu serveru. Zadejte název certifikátu a předmět certifikátu. Předmět je zadaný jako , kde zástupný symbol je běžný název CN={COMMON NAME} {COMMON NAME} certifikátu. Běžným názvem může být libovolný alfanumerický řetězec. Například je CN=IdentityServerSigning platným subjektem certifikátu. Použijte výchozí nastavení Konfigurace rozšířených zásad. Zaznamente si kryptografický otisk certifikátu, který se použije v konfiguraci aplikace později.

6. Přejděte na Azure App Service v Azure Portal a vytvořte nový App Service s následující konfigurací:

   • Publikovat nastavte na Code .
   • Zásobník modulu runtime nastavený na modul runtime aplikace.
   • V případě SKU a velikosti ověřte, že App Service je Basic B1 nebo vyšší. App Service používání vlastních Basic B1 domén vyžaduje úroveň služby nebo vyšší.

7. Jakmile Azure vytvoří App Service, otevřete konfiguraci aplikace a přidejte nové nastavení aplikace určující kryptografický otisk certifikátu zaznamenaný dříve. Klíč nastavení aplikace je WEBSITE_LOAD_CERTIFICATES . Kryptografický otisk certifikátu v hodnotě nastavení aplikace oddělte čárkou, jak ukazuje následující příklad:

   • Klíč: WEBSITE_LOAD_CERTIFICATES
   • Hodnota: 57443A552A46DB...D55E28D412B943565,29F43A772CB6AF...1D04F0C67F85FB0B1

   V Azure Portal je ukládání nastavení aplikace dvoukrokový proces: Uložte nastavení páru klíč-hodnota a pak vyberte tlačítko Uložit v WEBSITE_LOAD_CERTIFICATES horní části okna.

8. Vyberte nastavení TLS/SSL aplikace. Vyberte Certifikáty privátních klíčů (.pfx). Pomocí procesu Import Key Vault Certificate dvakrát naimportujte certifikát lokality pro komunikaci pomocí protokolu HTTPS i podpisový certifikát serveru podepsaný svým Identity držitelem.

9. Přejděte do okna Vlastní domény. Na webu doménového registrátora nakonfigurujte doménu Custom Domain IP adresu a ID ověření. Typická konfigurace domény zahrnuje:

   • Záznam A s hostitelem a @ hodnotou IP adresy z Azure Portal.
   • Záznam TXT s hostitelem a hodnotou ID ověření vygenerované Azure a poskytnutého asuid Azure Portal.

   Nezapomeňte změny správně uložit na webu doménového registrátora. Některé weby registrátora vyžadují dvoukrokový proces ukládání záznamů domény: Jeden nebo více záznamů se uloží jednotlivě a pak se registrace domény aktualizuje samostatným tlačítkem.

10. Vraťte se do okna Vlastní domény v Azure Portal. Vyberte Přidat vlastní doménu. Vyberte možnost Záznam A. Zadejte doménu a vyberte Ověřit. Pokud jsou záznamy domény správné a šíří se po internetu, portál umožňuje vybrat tlačítko Přidat vlastní doménu.

    Může trvat několik dnů, než se změny registrace domény rozšíří mezi internetové názvové servery domény (DNS) poté, co je zpracuje doménový registrátor. Pokud se záznamy domény ne aktualizují do tří pracovních dnů, ověřte, že jsou záznamy správně nastavené u doménového registrátora, a kontaktujte zákaznickou podporu.

11. V okně Vlastní domény je stav SSL pro doménu označený Not Secure jako . Vyberte odkaz Přidat vazbu. Vyberte certifikát HTTPS lokality z trezoru klíčů pro vlastní vazbu domény.

12. V Visual Studio otevřete soubor nastavení aplikace projektu serveru ( appsettings.json nebo appsettings.Production.json ). V Identity části Konfigurace serveru přidejte následující Key část. Zadejte předmět certifikátu podepsaného svým držitelem pro Name klíč. V následujícím příkladu je běžný název certifikátu přiřazený v trezoru klíčů . Výsledkem je IdentityServerSigning předmět CN=IdentityServerSigning :

    "IdentityServer": {
    
      ...
    
      "Key": {
        "Type": "Store",
        "StoreName": "My",
        "StoreLocation": "CurrentUser",
        "Name": "CN=IdentityServerSigning"
      }
    },
    

13. V Visual Studio vytvořit profil Azure App Service pro projekt Server. V řádku nabídek vyberte: Build > Publish > New > Azure Azure App Service (Windows or Linux ) (Publikovat nový Azure > Windows nebo Linux). Když Visual Studio k předplatnému Azure, můžete nastavit Zobrazení prostředků Azure podle typu prostředku. Přejděte do seznamu Webová aplikace, vyhledejte App Service aplikace a vyberte ji. Vyberte Dokončit.

14. Když Visual Studio do okna Publikovat, automaticky se detekují závislosti trezoru SQL Server a databázové služby.

    Pro službu trezoru klíčů nejsou potřeba žádné změny konfigurace výchozích nastavení.

    Pro účely testování je možné s aplikací nasadit místní databázi SQLite, která je ve výchozím nastavení nakonfigurovaná Blazor šablonou, bez další konfigurace. Konfigurace jiné databáze pro Identity Server v produkčním prostředí je nad rámec tohoto článku. Další informace najdete v databázových zdrojích v následujících sadách dokumentace:

    • App Service
    • Duende Identity Server

15. V horní části okna vyberte odkaz Upravit pod názvem profilu nasazení. Změňte cílovou adresu URL na adresu URL vlastní domény webu (například https://www.contoso.com ). Uložte nastavení.

16. Publikujte aplikaci. Visual Studio okno prohlížeče a požádá o web ve vlastní doméně.

Dokumentace k Azure obsahuje další podrobnosti o používání služeb Azure a vlastních domén s vazbou TLS v App Service, včetně informací o použití záznamů CNAME místo záznamů A. Další informace naleznete v následujících zdrojích:

• App Service dokumentace
• Kurz: Mapování existujícího vlastního názvu DNS na službu Azure App Service
• Zabezpečení vlastního názvu DNS pomocí vazby TLS/SSL v Azure App Service
• Azure Key Vault

Doporučujeme použít nové okno prohlížeče v soukromém nebo anonymním režimu pro každý test aplikace spuštěný po změně aplikace, konfigurace aplikace nebo služeb Azure v Azure Portal. Odstranění chyby z předchozího testovacího běhu může způsobit neúspěšné ověření nebo autorizaci při testování lokality, i když je konfigurace cookie lokality správná. Další informace o tom, jak Visual Studio pro každé testovací běhy otevřít nové okno prohlížeče v soukromém nebo anonymním režimu, najdete v části s a Cookie data webu.

Když App Service konfigurace v aplikaci Azure Portal, aktualizace se projeví rychle, ale nejsou okamžité. Někdy musíte chvíli počkat, než se App Service počítač restartuje, aby se změna konfigurace projeví.

Pokud chcete vyřešit problém s načítáním certifikátu, spusťte následující příkaz v Azure Portal prostředí PowerShell Kudu. Příkaz zobrazí seznam certifikátů, ke kterým má aplikace přístup z CurrentUser > My úložiště certifikátů. Výstup obsahuje předměty certifikátů a kryptografický otisk, které jsou užitečné při ladění aplikace:

Get-ChildItem -path Cert:\CurrentUser\My -Recurse | Format-List DnsNameList, Subject, Thumbprint, EnhancedKeyUsageList

Řešení potíží

Běžné chyby

• Chybné konfigurace aplikace nebo Identity zprostředkovatele (IP)

  Nejčastější chyby jsou způsobené nesprávnou konfigurací. Tady je několik příkladů:

  • V závislosti na požadavcích scénáře brání chybějící nebo nesprávná autorita, instance, ID tenanta, doména tenanta, ID klienta nebo identifikátor URI přesměrování aplikaci v ověřování klientů.
  • Nesprávný obor přístupového tokenu brání klientům v přístupu ke koncovým bodům webového rozhraní API serveru.
  • Nesprávná nebo chybějící oprávnění rozhraní API serveru brání klientům v přístupu ke koncovým bodům webového rozhraní API serveru.
  • Spuštění aplikace na jiném portu, než je nakonfigurované v identifikátoru URI přesměrování Identity registrace aplikace poskytovatele.

  V částech s pokyny pro konfiguraci najdete příklady správné konfigurace. Pečlivě zkontrolujte každou část článku a zkontrolujte chybné konfigurace aplikace a IP adresy.

  Pokud se konfigurace zdá být správná:

  • Analýza aplikačních protokolů

  • Prozkoumejte síťový provoz mezi klientskou aplikací a IP adresou nebo serverovou aplikací pomocí vývojářských nástrojů prohlížeče. Ip adresa nebo serverová aplikace často vrátí klientovi přesnou chybovou zprávu nebo zprávu s vodítkem k příčině problému. Vývojářské nástroje najdete v následujících článcích:

    • Google Chrome (dokumentace Google)
    • Microsoft Edge
    • Mozilla Firefox (dokumentace Mozilla)

  • Dekódujte obsah souboru JWT (JSON Web Token), který se používá k ověřování klienta nebo přístupu k webovému rozhraní API serveru v závislosti na tom, kde k problému dochází. Další informace najdete v tématu Kontrola obsahu souboru JSON WEB TOKEN (JWT).

  Dokumentační tým reaguje na zpětnou vazbu k dokumentům a chyby v článcích (otevřete problém v části Tato zpětná vazba na stránce), ale nemůže poskytovat podporu k produktům. Při řešení potíží s aplikací je k dispozici několik veřejných fór podpory. Doporučujeme postupovat následovně:

  • Stack Overflow (značka: blazor )
  • ASP.NET Core Slack Team
  • Blazor Gitter

  Předchozí fóra nejsou vlastněna ani řízena společností Microsoft.

  V případě zpráv o chybách architektury bez zabezpečení, bez citlivosti a bez důvěrných reprodukovatelných architektur otevřete problém v ASP.NET Core produktové jednotce. Neotevřete problém s produktovou jednotkou, dokud pečlivě neprošetříte příčinu problému a nemůžete ho vyřešit sami a s pomocí komunity na veřejném fóru podpory. Produktová jednotka nemůže řešit potíže s jednotlivými aplikacemi, které jsou poškozené kvůli jednoduché chybné konfiguraci nebo případům použití zahrnujícím služby třetích stran. Pokud je sestava citlivá nebo důvěrná nebo popisuje potenciální chybu zabezpečení v produktu, kterou mohou útočníci zneužít, podívejte se na téma Hlášení problémů a chyb zabezpečení (dotnet/aspnetcore GitHub úložiště).

• Neautorizovaný klient pro AAD

  info: Microsoft.AspNetCore.Authorization.DefaultAuthorizationService[2] Autorizace se nezdařila. Tyto požadavky nebyly splněny: DenyAnonymousAuthorizationRequirement: Vyžaduje ověřeného uživatele.

  Chyba zpětného volání přihlášení z AAD:

  • Chyba: unauthorized_client
  • Popis: AADB2C90058: The provided application is not configured to allow public clients.

  Řešení chyby:

  1. V Azure Portal přístup k manifestu aplikace.
  2. Nastavte allowPublicClient atribut na null nebo true .

Cookies a data lokality

CookieData webů a se mohou uchovat napříč aktualizacemi aplikací a interferovat s testováním a řešením potíží. Při provádění změn kódu aplikace, změn uživatelského účtu u poskytovatele nebo změn konfigurace aplikace zprostředkovatele vymažte následující:

• Přihlášení cookie uživatele
• Aplikace cookie
• Uložená data lokality a uložená v mezipaměti

Jedním z přístupů, jak zabránit tomu, aby se při testování a řešení potíží přerušují cookie data lokality, je:

• Konfigurace prohlížeče
  • Pro testování použijte prohlížeč, který můžete nakonfigurovat tak, aby při každém zavření prohlížeče odstranil všechna data a cookie data webu.
  • Ujistěte se, že je prohlížeč ručně zavřen nebo integrované vývojové prostředí (IDE) kvůli jakékoli změně konfigurace aplikace, testovacího uživatele nebo zprostředkovatele.
• Pomocí vlastního příkazu otevřete prohlížeč v anonymním nebo privátním režimu v Visual Studio:
  • V dialogovém okně Procházet Visual Studio tlačítko Spustit.
  • Vyberte tlačítko Přidat.
  • Do pole Program zadejte cestu k prohlížeči. Následující spustitelné cesty jsou typická umístění instalace pro Windows 10. Pokud je váš prohlížeč nainstalovaný na jiném místě nebo pokud ho Windows 10, zadejte cestu ke spustitelnému souboru prohlížeče.
    • Microsoft Edge:C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
    • Google Chrome: C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
    • Mozilla Firefox: C:\Program Files\Mozilla Firefox\firefox.exe
  • Do pole Argumenty zadejte možnost příkazového řádku, kterou prohlížeč používá k otevření v anonymním nebo privátním režimu. Některé prohlížeče vyžadují adresu URL aplikace.
    • Microsoft Edge: Použijte -inprivate .
    • Google Chrome: Použijte --incognito --new-window {URL} , kde zástupný symbol je adresa URL, která se má otevřít {URL} (například https://localhost:5001 ).
    • Mozilla Firefox: Použijte -private -url {URL} , kde zástupný symbol je adresa URL, která se má otevřít {URL} (například https://localhost:5001 ).
  • Do pole Popisný název zadejte název. Například, Firefox Auth Testing.
  • Vyberte tlačítko OK.
  • Pokud se chcete vyhnout výběru profilu prohlížeče pro každou iteraci testování pomocí aplikace, nastavte profil jako výchozí pomocí tlačítka Nastavit jako výchozí.
  • Ujistěte se, že integrované vývojové prostředí zavře prohlížeč kvůli jakékoli změně konfigurace aplikace, testovacího uživatele nebo zprostředkovatele.

Upgrady aplikací

Funkční aplikace může selhat okamžitě po upgradu .NET Core SDK na vývojovém počítači nebo změně verzí balíčků v rámci aplikace. V některých případech může při provádění významných upgradů dojít k přerušení aplikace v neschválených balíčcích. Většinu těchto problémů můžete vyřešit pomocí těchto pokynů:

1. Vymažte mezipaměť balíčků NuGet systému spuštěním příkazu dotnet nuget locals all --clear z příkazového prostředí.
2. Odstraňte složky a bin obj projektu.
3. Obnovte a znovu sestavte projekt.
4. Před znovunasazování aplikace odstraňte všechny soubory ve složce nasazení na serveru.

Spuštění aplikace Server

Při testování hostovaného řešení a řešení souvisejících potíží se ujistěte, že aplikaci používáte Blazor z Server projektu. Například v Visual Studio před zahájením aplikace potvrďte, že je projekt Server zvýrazněný v Průzkumník řešení, a to pomocí libovolného z následujících přístupů:

• Vyberte tlačítko Run (Spustit).
• V nabídce > použijte Ladění spustit ladění.
• Stiskněte klávesu F5.

Kontrola obsahu souboru JSON Web Token (JWT)

Pokud chcete dekódovat JSON Web Token (JWT), použijte nástroj jwt.ms Microsoftu. Hodnoty v uživatelském rozhraní nikdy neopustí váš prohlížeč.

Příklad kódovaného JWT (zkráceně pro zobrazení):

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIsImtpZCI6Ilg1ZVhrNHh5b2pORnVtMWtsMll0djhkbE5QNC1j... bQdHBHGcQQRbW7Wmo6SWYG4V_bU55Ug_PW4pLPr20tTS8Ct7_uwy9DWrzCMzpD-EiwT5IjXwlGX3IXVjHIlX50IVIydBoPQtadvT7saKo1G5Jmutgq41o-dmz6-yBMKV2_nXA25Q

Příklad JWT dekódovaný nástrojem pro aplikaci, která se ověřuje vůči Azure AAD B2C:

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "X5eXk4xyojNFum1kl2Ytv8dlNP4-c57dO6QGTVBwaNk"
}.{
  "exp": 1610059429,
  "nbf": 1610055829,
  "ver": "1.0",
  "iss": "https://mysiteb2c.b2clogin.com/5cc15ea8-a296-4aa3-97e4-226dcc9ad298/v2.0/",
  "sub": "5ee963fb-24d6-4d72-a1b6-889c6e2c7438",
  "aud": "70bde375-fce3-4b82-984a-b247d823a03f",
  "nonce": "b2641f54-8dc4-42ca-97ea-7f12ff4af871",
  "iat": 1610055829,
  "auth_time": 1610055822,
  "idp": "idp.com",
  "tfp": "B2C_1_signupsignin"
}.[Signature]

Další zdroje informací

• Nasazení do Azure App Service
• Import certifikátu z Key Vault (dokumentace Azure)
• Blazor WebAssemblyASP.NET Core další scénáře zabezpečení
• Neověřené nebo neoprávněné požadavky webového rozhraní API v aplikaci se zabezpečeným výchozím klientem
• Konfigurace ASP.NET Core pro práci s proxy servery a nástroji pro vyrovnávání zatížení: Obsahuje pokyny pro:
  • Použití middlewaru forwarded headers k zachování informací schématu HTTPS mezi proxy servery a interními sítěmi.
  • Další scénáře a případy použití, včetně ruční konfigurace schématu, změn cesty požadavku pro správné směrování požadavků a předávání schématu požadavků pro linuxové a jiné reverzní servery než IIS.
• Duende Identity Server

Tento článek vysvětluje, jak vytvořit hostované Blazor WebAssembly řešení, které používá Identity Server k ověřování uživatelů a volání rozhraní API.

dotnet new blazorwasm -au Individual -ho -o {APP NAME}

Server konfigurace aplikace

V následujících částech jsou popsány dodatky k projektu, pokud je zahrnuta podpora ověřování.

Startup – třída

Třída Startup má následující doplňky.

• V Startup.ConfigureServices:

  • ASP.NET Core Identity:

    services.AddDbContext<ApplicationDbContext>(options =>
        options.UseSqlite(
            Configuration.GetConnectionString("DefaultConnection")));
    
    services.AddDefaultIdentity<ApplicationUser>(options => 
            options.SignIn.RequireConfirmedAccount = true)
        .AddEntityFrameworkStores<ApplicationDbContext>();
    

  • IdentityServer s další AddApiAuthorization pomocná metoda, která nastavuje výchozí ASP.NET Core konvence na Identity serveru:

    services.AddIdentityServer()
        .AddApiAuthorization<ApplicationUser, ApplicationDbContext>();
    

  • Ověřování pomocí další pomocné metody, která konfiguruje aplikaci tak, aby ověřoval AddIdentityServerJwt tokeny JWT vytvořené Identity serverem:

    services.AddAuthentication()
        .AddIdentityServerJwt();
    

• V Startup.Configure:

  • Middleware Identity Serveru zpřístupňuje koncové body openid Připojení (OIDC):

    app.UseIdentityServer();
    

  • Middleware pro ověřování zodpovídá za ověřování přihlašovacích údajů požadavků a nastavení uživatele v kontextu požadavku:

    app.UseAuthentication();
    

  • Autorizační middleware umožňuje funkce autorizace:

    app.UseAuthorization();
    

Azure App Service v Linuxu

Explicitně zadejte vystavitele při nasazování do Azure App Service v Linuxu. Další informace naleznete v tématu Úvod do ověřování pro jedno stránkové aplikace v ASP.NET Core.

AddApiAuthorization

Pomocná AddApiAuthorization metoda nakonfiguruje Identity Server pro ASP.NET Core scénářů. IdentityServer je výkonná a rozšiřitelná rozhraní pro řešení problémů se zabezpečením aplikací. IdentityServer zveřejňuje nepotřebnou složitost pro nejběžnější scénáře. V důsledku toho je k dispozici sada konvencí a možností konfigurace, které považujeme za dobrý výchozí bod. Jakmile se vaše potřeby ověřování změní, Identity je k dispozici plná síla serveru pro přizpůsobení ověřování podle požadavků aplikace.

Přidat Identity ServerJwt

AddIdentityServerJwtPomocná metoda nakonfiguruje schéma zásad pro aplikaci jako výchozí obslužnou rutinu ověřování. Zásady jsou nakonfigurovány tak, aby umožňovaly Identity zpracování všech požadavků směrovaných na jakoukoli dílčí cestu v Identity prostoru URL /Identity . JwtBearerHandlerZpracovává všechny ostatní požadavky. Tato metoda navíc:

• Zaregistruje {APPLICATION NAME}API prostředek rozhraní API se Identity serverem s výchozím oborem {APPLICATION NAME}API .
• Konfiguruje middleware tokenu JWT nosiče k ověření tokenů vydaných Identity serverem pro aplikaci.

WeatherForecastController

V rozhraní WeatherForecastController ( Controllers/WeatherForecastController.cs ) je [Authorize] atribut použit pro třídu. Atribut označuje, že uživatel musí být autorizovaný na základě výchozích zásad pro přístup k prostředku. Výchozí zásada autorizace je nakonfigurovaná tak, aby používala výchozí schéma ověřování, které je nastavené nástrojem AddIdentityServerJwt . Pomocná metoda se konfiguruje JwtBearerHandler jako výchozí obslužná rutina pro požadavky na aplikaci.

ApplicationDbContext

V rozhraní ApplicationDbContext ( Data/ApplicationDbContext.cs ) se DbContext rozšiřuje ApiAuthorizationDbContext<TUser> na zahrnutí schématu pro Identity Server. ApiAuthorizationDbContext<TUser> je odvozen z IdentityDbContext .

Chcete-li získat úplné řízení schématu databáze, zdědit jednu z dostupných Identity DbContext tříd a nakonfigurovat kontext pro zahrnutí Identity schématu voláním builder.ConfigurePersistedGrantContext(_operationalStoreOptions.Value) v OnModelCreating metodě.

OidcConfigurationController

V rozhraní OidcConfigurationController ( Controllers/OidcConfigurationController.cs ) se koncový bod klienta zřídí pro poskytování OIDC parametrů.

Nastavení aplikace

V souboru nastavení aplikace ( appsettings.json ) v kořenovém adresáři projektu IdentityServer obsahuje část seznam konfigurovaných klientů. V následujícím příkladu je jeden klient. Název klienta odpovídá názvu aplikace a je mapován podle konvence na ClientId parametr OAuth. Profil indikuje typ aplikace, která se konfiguruje. Profil se interně používá k tomu, aby bylo možné řídit konvence, které zjednodušují proces konfigurace serveru.

"IdentityServer": {
  "Clients": {
    "{APP ASSEMBLY}.Client": {
      "Profile": "IdentityServerSPA"
    }
  }
}

Zástupný symbol {APP ASSEMBLY} je název sestavení aplikace (například BlazorSample.Client ).

Client Konfigurace aplikace

Ověřovací balíček

Když je aplikace vytvořená tak, aby používala jednotlivé uživatelské účty ( Individual ), aplikace automaticky obdrží odkaz na balíček Microsoft.AspNetCore.Components.WebAssembly.Authentication v souboru projektu aplikace. Balíček poskytuje sadu primitivních elementů, které aplikaci pomůžou ověřit uživatele a získat tokeny pro volání chráněných rozhraní API.

Pokud se do aplikace přidává ověřování, přidejte balíček do souboru projektu aplikace ručně:

<PackageReference 
  Include="Microsoft.AspNetCore.Components.WebAssembly.Authentication" 
  Version="{VERSION}" />

pro zástupný text je k {VERSION} dispozici nejnovější stabilní verze balíčku, která odpovídá verzi sdílené architektury aplikace, v historii verzí balíčku na adrese NuGet. org.

HttpClient rozšířeného

V aplikaci Program.cs je pojmenovaná HttpClient ( {APP ASSEMBLY}.ServerAPI ) nakonfigurovaná tak, aby poskytovala HttpClient instance, které zahrnují přístupové tokeny při vytváření žádostí na rozhraní API serveru:

builder.Services.AddHttpClient("{APP ASSEMBLY}.ServerAPI", 
        client => client.BaseAddress = new Uri(builder.HostEnvironment.BaseAddress))
    .AddHttpMessageHandler<BaseAddressAuthorizationMessageHandler>();

builder.Services.AddScoped(sp => sp.GetRequiredService<IHttpClientFactory>()
    .CreateClient("{APP ASSEMBLY}.ServerAPI"));

Zástupný symbol {APP ASSEMBLY} je název sestavení aplikace (například BlazorSample.Client ).

Podpora autorizace rozhraní API

Podpora ověřování uživatelů je zapojena do kontejneru služby prostřednictvím metody rozšíření poskytované v rámci Microsoft.AspNetCore.Components.WebAssembly.Authentication balíčku. Tato metoda nastaví služby, které aplikace požaduje, aby spolupracovaly se stávajícím autorizačním systémem.

builder.Services.AddApiAuthorization();

Ve výchozím nastavení je konfigurace pro aplikaci načtena podle konvence z _configuration/{client-id} . Podle konvence je ID klienta nastaveno na název sestavení aplikace. Tato adresa URL může být změněna tak, aby odkazovala na samostatný koncový bod voláním přetížení s možnostmi.

Importovat soubor

Obor Microsoft.AspNetCore.Components.Authorization názvů je k dispozici v celé aplikaci prostřednictvím souboru _Imports.razor :

@using System.Net.Http
@using System.Net.Http.Json
@using Microsoft.AspNetCore.Components.Authorization
@using Microsoft.AspNetCore.Components.Forms
@using Microsoft.AspNetCore.Components.Routing
@using Microsoft.AspNetCore.Components.Web
@using Microsoft.AspNetCore.Components.Web.Virtualization
@using Microsoft.AspNetCore.Components.WebAssembly.Http
@using Microsoft.JSInterop
@using {APPLICATION ASSEMBLY}.Client
@using {APPLICATION ASSEMBLY}.Client.Shared

Indexová stránka

Stránka Index wwwroot/index.html (Index) obsahuje skript, který definuje v AuthenticationService JavaScriptu. AuthenticationService zpracovává podrobnosti nízké úrovně protokolu OIDC. Aplikace interně volá metody definované ve skriptu k provedení ověřovacích operací.

<script src="_content/Microsoft.AspNetCore.Components.WebAssembly.Authentication/
    AuthenticationService.js"></script>

Součást aplikace

AppSoučást ( App.razor ) je podobná App komponentě, kterou najdete v Blazor Server aplikacích:

• Komponenta spravuje vystavení CascadingAuthenticationState AuthenticationState do zbytku aplikace.
• AuthorizeRouteViewKomponenta zajistí, že aktuální uživatel má oprávnění pro přístup k dané stránce nebo jinak vykreslí RedirectToLogin součást.
• RedirectToLoginKomponenta spravuje přesměrování neautorizovaných uživatelů na přihlašovací stránku.

v důsledku změn v rozhraní napříč verzemi ASP.NET Core se Razor App App.razor v této části nezobrazí značka pro komponentu (). Chcete-li zkontrolovat označení komponenty pro danou verzi, použijte některý z následujících přístupů:

• vytvořte aplikaci zřízenou pro ověřování z výchozí Blazor WebAssembly šablony projektu pro verzi ASP.NET Core, kterou chcete použít. Zkontrolujte App součást ( App.razor ) ve vygenerované aplikaci.

• Zkontrolujte App součást ( App.razor ) v referenčním zdroji.

  Poznámka

  dokumentace odkazuje na zdrojový odkaz na ASP.NET Core načtení main větve úložiště, která představuje aktuální vývoj jednotky produktu pro další verzi ASP.NET Core. Pokud chcete vybrat větev pro jinou verzi, vyberte ji pomocí rozevíracího seznamu větve přepínače nebo značky . vyberte například release/5.0 větev pro verzi ASP.NET Core 5,0.

Komponenta RedirectToLogin

RedirectToLoginSoučást ( Shared/RedirectToLogin.razor ):

• Spravuje přesměrování neautorizovaných uživatelů na přihlašovací stránku.
• Zachová aktuální adresu URL, ke které se uživatel pokouší získat přístup, aby se mohla vrátit na tuto stránku, pokud je ověření úspěšné.

@inject NavigationManager Navigation
@using Microsoft.AspNetCore.Components.WebAssembly.Authentication
@code {
    protected override void OnInitialized()
    {
        Navigation.NavigateTo(
            $"authentication/login?returnUrl={Uri.EscapeDataString(Navigation.Uri)}");
    }
}

Komponenta LoginDisplay

LoginDisplaySoučást ( Shared/LoginDisplay.razor ) je vykreslena v MainLayout komponentě ( Shared/MainLayout.razor ) a spravuje následující chování:

• Pro ověřené uživatele:
  • Zobrazí aktuální uživatelské jméno.
  • Nabízí odkaz na stránku profil uživatele v ASP.NET Core Identity .
  • Nabízí tlačítko pro odhlášení od aplikace.
• Pro anonymní uživatele:
  • Nabízí možnost registrace.
  • Nabízí možnost přihlásit se.

@using Microsoft.AspNetCore.Components.Authorization
@using Microsoft.AspNetCore.Components.WebAssembly.Authentication
@inject NavigationManager Navigation
@inject SignOutSessionStateManager SignOutManager

<AuthorizeView>
    <Authorized>
        <a href="authentication/profile">Hello, @context.User.Identity.Name!</a>
        <button class="nav-link btn btn-link" @onclick="BeginSignOut">
            Log out
        </button>
    </Authorized>
    <NotAuthorized>
        <a href="authentication/register">Register</a>
        <a href="authentication/login">Log in</a>
    </NotAuthorized>
</AuthorizeView>

@code {
    private async Task BeginSignOut(MouseEventArgs args)
    {
        await SignOutManager.SetSignOutState();
        Navigation.NavigateTo("authentication/logout");
    }
}

Součást ověřování

Stránka vytvořená komponentou ( ) definuje trasy vyžadované Authentication pro zpracování různých fází Pages/Authentication.razor ověřování.

RemoteAuthenticatorViewKomponenta:

• Je poskytován Microsoft.AspNetCore.Components.WebAssembly.Authentication balíčkem .
• Spravuje provádění příslušných akcí v každé fázi ověřování.

@page "/authentication/{action}"
@using Microsoft.AspNetCore.Components.WebAssembly.Authentication

<RemoteAuthenticatorView Action="@Action" />

@code {
    [Parameter]
    public string Action { get; set; }
}

Komponenta FetchData

Tato FetchData součást ukazuje, jak:

• Zřízení přístupového tokenu
• Pomocí přístupového tokenu v serverové aplikaci zavolejte chráněné rozhraní API prostředků.

Tato @attribute [Authorize] direktiva indikuje Blazor WebAssembly autorizačnímu systému, že uživatel musí být autorizovaný, aby mohl navštívit tuto součást. Přítomnost atributu v Client aplikaci nebrání volání rozhraní API na serveru bez správných přihlašovacích údajů. Server [Authorize] K jejich správné ochraně musí aplikace také použít příslušné koncové body.

IAccessTokenProvider.RequestAccessToken postará o vyžadování přístupového tokenu, který se dá přidat do žádosti o volání rozhraní API. Pokud je token uložen v mezipaměti nebo služba může zřídit nový přístupový token bez zásahu uživatele, požadavek na token je úspěšný. V opačném případě požadavek tokenu selže s objektem AccessTokenNotAvailableException , který je zachycen v try-catch příkazu.

Aby bylo možné získat skutečný token, který se má zahrnout do žádosti, musí aplikace ověřit, jestli žádost proběhla úspěšně voláním tokenResult.TryGetToken(out var token) .

Pokud byl požadavek úspěšný, je proměnná tokenu naplněná přístupovým tokenem. AccessToken.ValueVlastnost tokenu zpřístupňuje řetězec literálu, který má být zahrnut v Authorization hlavičce požadavku.

Pokud se žádost nezdařila, protože se token nepodařilo zřídit bez zásahu uživatele, výsledek tokenu obsahuje adresu URL pro přesměrování. Když přejdete na tuto adresu URL, uživatel přejde na přihlašovací stránku a vrátí se zpátky na aktuální stránku po úspěšném ověření.

@page "/fetchdata"
@using Microsoft.AspNetCore.Authorization
@using Microsoft.AspNetCore.Components.WebAssembly.Authentication
@using {APP NAMESPACE}.Shared
@attribute [Authorize]
@inject HttpClient Http

...

@code {
    private WeatherForecast[] forecasts;

    protected override async Task OnInitializedAsync()
    {
        try
        {
            forecasts = await Http.GetFromJsonAsync<WeatherForecast[]>("WeatherForecast");
        }
        catch (AccessTokenNotAvailableException exception)
        {
            exception.Redirect();
        }
    }
}

Spuštění aplikace

Spusťte aplikaci z projektu serveru. při použití Visual Studio se jedná o jednu z těchto akcí:

• Nastavte rozevírací seznam projekty po spuštění na panelu nástrojů na aplikaci API serveru a vyberte tlačítko Spustit .
• Vyberte projekt serveru v Průzkumník řešení a na panelu nástrojů vyberte tlačítko Spustit nebo spusťte aplikaci z nabídky ladění .

Deklarace identity u názvů a rolí pomocí ověřování API

Vlastní továrna uživatelů

V Client aplikaci vytvořte vlastní objekt pro vytváření uživatelů. Identity Server odesílá v jedné deklaraci více rolí jako pole JSON role . Jedna role se pošle jako řetězcová hodnota v deklaraci identity. Továrna vytvoří jednotlivou role deklaraci identity pro každou roli uživatele.

CustomUserFactory.cs:

using System.Linq;
using System.Security.Claims;
using System.Text.Json;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Components.WebAssembly.Authentication;
using Microsoft.AspNetCore.Components.WebAssembly.Authentication.Internal;

public class CustomUserFactory
    : AccountClaimsPrincipalFactory<RemoteUserAccount>
{
    public CustomUserFactory(IAccessTokenProviderAccessor accessor)
        : base(accessor)
    {
    }

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

        if (user.Identity.IsAuthenticated)
        {
            var identity = (ClaimsIdentity)user.Identity;
            var roleClaims = identity.FindAll(identity.RoleClaimType).ToArray();

            if (roleClaims.Any())
            {
                foreach (var existingClaim in roleClaims)
                {
                    identity.RemoveClaim(existingClaim);
                }

                var rolesElem = account.AdditionalProperties[identity.RoleClaimType];

                if (rolesElem is JsonElement roles)
                {
                    if (roles.ValueKind == JsonValueKind.Array)
                    {
                        foreach (var role in roles.EnumerateArray())
                        {
                            identity.AddClaim(new Claim(options.RoleClaim, role.GetString()));
                        }
                    }
                    else
                    {
                        identity.AddClaim(new Claim(options.RoleClaim, roles.GetString()));
                    }
                }
            }
        }

        return user;
    }
}

V Client aplikaci Zaregistrujte továrnu v Program.cs :

builder.Services.AddApiAuthorization()
    .AddAccountClaimsPrincipalFactory<CustomUserFactory>();

V Server aplikaci zavolejte AddRoles na Identity Tvůrce, který přidá služby související s rolemi:

using Microsoft.AspNetCore.Identity;

...

services.AddDefaultIdentity<ApplicationUser>(options => 
    options.SignIn.RequireConfirmedAccount = true)
    .AddRoles<IdentityRole>()
    .AddEntityFrameworkStores<ApplicationDbContext>();

Konfigurovat Identity Server

Použijte jeden z následujících přístupů:

• Možnosti autorizace rozhraní API
• Profilová služba

Možnosti autorizace rozhraní API

V Server aplikaci:

• Nakonfigurujte Identity Server tak, aby name uvedl role deklarace identity a do tokenu ID a přístupového tokenu.
• Zabrání výchozímu mapování rolí v obslužné rutině tokenu JWT.

using System.IdentityModel.Tokens.Jwt;
using System.Linq;

...

services.AddIdentityServer()
    .AddApiAuthorization<ApplicationUser, ApplicationDbContext>(options => {
        options.IdentityResources["openid"].UserClaims.Add("name");
        options.ApiResources.Single().UserClaims.Add("name");
        options.IdentityResources["openid"].UserClaims.Add("role");
        options.ApiResources.Single().UserClaims.Add("role");
    });

JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Remove("role");

Profilová služba

V Server aplikaci vytvořte ProfileService implementaci.

ProfileService.cs:

using IdentityModel;
using IdentityServer4.Models;
using IdentityServer4.Services;
using System.Threading.Tasks;

public class ProfileService : IProfileService
{
    public ProfileService()
    {
    }

    public async Task GetProfileDataAsync(ProfileDataRequestContext context)
    {
        var nameClaim = context.Subject.FindAll(JwtClaimTypes.Name);
        context.IssuedClaims.AddRange(nameClaim);

        var roleClaims = context.Subject.FindAll(JwtClaimTypes.Role);
        context.IssuedClaims.AddRange(roleClaims);

        await Task.CompletedTask;
    }

    public async Task IsActiveAsync(IsActiveContext context)
    {
        await Task.CompletedTask;
    }
}

V Server aplikaci Zaregistrujte službu profilů v nástroji Startup.ConfigureServices :

using IdentityServer4.Services;

...

services.AddTransient<IProfileService, ProfileService>();

JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Remove("role");

Použití autorizačních mechanismů

V Client této aplikaci jsou v tuto chvíli funkční přístupy k komponentám autorizace. Kterýkoli z autorizačních mechanismů v součástech může použít roli k autorizaci uživatele:

• AuthorizeView součást (příklad: <AuthorizeView Roles="admin"> )

• [Authorize] direktiva atributu ( AuthorizeAttribute ) (příklad: @attribute [Authorize(Roles = "admin")] )

• Procedurální logika (příklad: if (user.IsInRole("admin")) { ... } )

  Podporuje se vícenásobné testy rolí:

  if (user.IsInRole("admin") && user.IsInRole("developer"))
  {
      ...
  }
  

User.Identity.Name aplikace se v aplikaci naplní Client uživatelským jménem uživatele, což je obvykle jejich přihlašovací e-mailová adresa.

UserManager a SignInManager

Nastavte typ deklarace identity identifikátoru uživatele, když serverová aplikace vyžaduje:

• UserManager<TUser> nebo SignInManager<TUser> v koncovém bodu rozhraní API.
• IdentityUser podrobnosti, jako je jméno uživatele, e-mailová adresa nebo koncový čas uzamčení.

In Program.cs pro ASP.NET Core 6.0 nebo novější:

using System.Security.Claims;

...

builder.Services.Configure<IdentityOptions>(options => 
    options.ClaimsIdentity.UserIdClaimType = ClaimTypes.NameIdentifier);

Ve Startup.ConfigureServices verzi ASP.NET Core starší než 6.0:

using System.Security.Claims;

...

services.Configure<IdentityOptions>(options => 
    options.ClaimsIdentity.UserIdClaimType = ClaimTypes.NameIdentifier);

Následující kód WeatherForecastController UserName protokoluje, kdy Get je volána metoda :

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Identity;
using Microsoft.Extensions.Logging;
using {APP NAMESPACE}.Server.Models;
using {APP NAMESPACE}.Shared;

namespace {APP NAMESPACE}.Server.Controllers
{
    [Authorize]
    [ApiController]
    [Route("[controller]")]
    public class WeatherForecastController : ControllerBase
    {
        private readonly UserManager<ApplicationUser> userManager;

        private static readonly string[] Summaries = new[]
        {
            "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", 
            "Balmy", "Hot", "Sweltering", "Scorching"
        };

        private readonly ILogger<WeatherForecastController> logger;

        public WeatherForecastController(ILogger<WeatherForecastController> logger, 
            UserManager<ApplicationUser> userManager)
        {
            this.logger = logger;
            this.userManager = userManager;
        }

        [HttpGet]
        public async Task<IEnumerable<WeatherForecast>> Get()
        {
            var rng = new Random();

            var user = await userManager.GetUserAsync(User);

            if (user != null)
            {
                logger.LogInformation($"User.Identity.Name: {user.UserName}");
            }

            return Enumerable.Range(1, 5).Select(index => new WeatherForecast
            {
                Date = DateTime.Now.AddDays(index),
                TemperatureC = rng.Next(-20, 55),
                Summary = Summaries[rng.Next(Summaries.Length)]
            })
            .ToArray();
        }
    }
}

Scénáře podepisování tokenů pomocí Azure App Service

Jsou pokryty dva scénáře. Postupujte podle pokynů v jedné z následujících částí:

• Hostování v Azure App Service s automatickým podpisem tokenu a zabezpečením klíče ochrany dat pomocí Azure Key Vault
• Hostitel v Azure App Service s podepisováním tokenu certifikátu

Hostování v Azure App Service s automatickým podpisem tokenu a zabezpečením klíče ochrany dat pomocí Azure Key Vault

Pokyny v této části popisují:

• Postup nasazení hostované Blazor WebAssembly aplikace se Identity serverem pro Azure App Service.
• Jak používat automatické Identity podepisování tokenů serveru s klíči ochrany dat zabezpečenými Azure Key Vault.

1. Vytvořte plán App Service.

   Poznámka

   Basic B1Pokud plánujete použít jednu nebo více vlastních domén s aplikací, je potřeba, abyste naplánovali App Service plán s úrovní plánu nebo vyšší úrovně.

2. Vytvořte novou Azure Key Vault nebo použijte existující Trezor klíčů v předplatném Azure.

3. V Azure Portal přejděte na Azure App Service a vytvořte novou App Service s následující konfigurací:

   • Publikování je nastaveno na Code .
   • Zásobník modulu runtime nastavený na modul runtime aplikace
   • V případě SKU a velikosti potvrďte, že je úroveň App Service Basic B1 nebo vyšší, pokud také plánujete použít vlastní doménu. App Service vyžaduje, Basic B1 aby úroveň služby nebo vyšší používala vlastní domény.

4. nakonfigurujte aplikaci tak, aby používala automatické podepisování tokenů a Azure Key Vault ukládat a chránit ASP.NET Core klíče ochrany dat:

   Identity Podepisování tokenu serveru je ve výchozím nastavení automatické. IdentityServer také používá ASP.NET Core ochranu dat ve výchozím nastavení. Pro tyto funkce není potřeba žádná konfigurace v aplikaci. Další informace najdete v tématu Automatická správa klíčů (dokumentace k Duende softwaru).

   aplikace vyžaduje konfiguraci, aby používala Azure Key Vault k ukládání a ochraně klíčů používaných pro ASP.NET Core ochrany dat. pro konfiguraci požadovaných funkcí použijte pokyny v následujících ASP.NET Corech materiálech dokumentace:

   • Zachování klíčů do Azure Blob Storage
   • Konfigurace ochrany dat: ProtectKeysWithAzureKeyVault

5. v Visual Studio vytvořte Azure App Service publikační profil pro serverový projekt. v řádku nabídek vyberte: sestavit > publikovat > novou službu > Azure > Azure App Service (Windows nebo Linux). když je Visual Studio připojená k předplatnému azure, můžete si nastavit zobrazení prostředků Azure podle typu prostředku. Přejděte v seznamu webové aplikace , vyhledejte App Service pro aplikaci a vyberte ji. Vyberte Dokončit.

6. když se Visual Studio vrátí do okna publikovat , automaticky se zjistí závislosti klíčů a služby SQL Server database.

   Pro službu trezoru klíčů se nevyžadují žádné změny konfigurace výchozích nastavení.

   Pro účely testování je možné nasadit místní databázi SQLite aplikace, která je nakonfigurovaná ve výchozím nastavení Blazor šablonou, a to bez další konfigurace. Konfigurace jiné databáze pro Identity Server v produkčním prostředí je mimo rámec tohoto článku. Další informace najdete v tématu prostředky databáze v následujících sadách dokumentace:

   • App Service
   • Identity WebServer

7. Publikujte aplikaci. Visual Studio otevře okno prohlížeče a požádá o web.

Dokumentace k Azure obsahuje další podrobnosti o používání služeb Azure. Podívejte se na následující zdroje informací:

• Dokumentace k App Service
• Azure Key Vault

Pro každý testovací běh aplikace po změně aplikace, konfigurace aplikace nebo služeb Azure v Azure Portal doporučujeme použít nové soukromé nebo anonymním okno prohlížeče. cookiePři záchodu s z předchozího testovacího běhu může dojít k selhání ověřování nebo autorizaci při testování lokality i v případě, že je Konfigurace lokality správná. další informace o tom, jak nakonfigurovat Visual Studio pro otevření nového okna prohlížeče v privátním nebo anonymním pro každý testovací běh, najdete v části Cookie s a daty webu .

Když se v Azure Portal změní konfigurace App Service, obecně se tyto aktualizace projeví rychleji, ale ne okamžitě. V některých případech je třeba počkat krátce App Service restartováním, aby se změna konfigurace projevila.

Hostitel v Azure App Service s podepisováním tokenu certifikátu

Pokyny v této části popisují:

• Postup nasazení hostované Blazor WebAssembly aplikace se Identity serverem pro Azure App Service.
• Jak vytvořit a používat certifikát TLS pro Identity Podepisování tokenu serveru

V následujících pokynech se certifikát podepsaný svým držitelem vytvoří v Azure Key Vault výhradně pro Identity Podepisování tokenu serveru. Identitykonfigurace serveru používá certifikát trezoru klíčů pro Windows App Service a Linux , a to po různých přístupech App Service:

• Windows App Service: v aplikaci se k CurrentUser > My úložišti certifikátů aplikace přistupovalo, aby se mohl načíst certifikát.
• Linux App Service: aplikace načte certifikát ručně.

Konfigurace aplikace, Azure App Service a Azure Key Vault pro hostování s vlastním podpisovým certifikátem tokenu:

1. Vytvořte plán App Service.

   Poznámka

   Basic B1Pokud plánujete použít jednu nebo více vlastních domén s aplikací, je potřeba, abyste naplánovali App Service plán s úrovní plánu nebo vyšší úrovně.

2. Vytvořte novou Azure Key Vault nebo použijte existující Trezor klíčů v předplatném Azure.

3. V Azure Key Vault Vygenerujte nový certifikát podepsaný svým držitelem pro Identity Podepisování tokenu serveru. Zadejte název certifikátu a Předmět. Předmět je určen jako CN={COMMON NAME} , kde {COMMON NAME} zástupný symbol je běžný název certifikátu. Běžným názvem může být libovolný alfanumerický řetězec. Například CN=IdentityServerSigning je platný Předmět certifikátu. Použijte výchozí Rozšířená nastavení konfigurace zásad .

   Chcete-li vytvořit certifikát, použijte jeden z následujících přístupů nebo jakýkoli jiný vhodný nástroj nebo online službu:

   • Azure Key Vault
   • MakeCert pro Windows
   • OpenSSL

   Poznamenejte si kryptografický otisk certifikátu, který se v konfiguraci aplikace používá později.

   Další informace o Azure Key Vaultch certifikátech najdete v článku Azure Key Vault: certifikáty.

4. V Azure Portal přejděte na Azure App Service a vytvořte novou App Service s následující konfigurací:

   • Publikování je nastaveno na Code .
   • Zásobník modulu runtime nastavený na modul runtime aplikace
   • V poli SKU a velikost potvrďte, že je úroveň App Service Basic B1 nebo vyšší. App Service vyžaduje, Basic B1 aby úroveň služby nebo vyšší používala vlastní domény.

5. Až Azure vytvoří App Service, otevřete konfiguraci aplikace a přidejte nové nastavení aplikace s určením kryptografického otisku certifikátu, který jste si poznamenali dříve. Klíč nastavení aplikace WEBSITE_LOAD_CERTIFICATES :

   • Klíč: WEBSITE_LOAD_CERTIFICATES
   • Hodnota: 57443A552A46DB...D55E28D412B943565

   V Azure Portal je ukládání nastavení aplikace dvoustupňový proces: uložte WEBSITE_LOAD_CERTIFICATES nastavení klíč-hodnota a potom v horní části okna vyberte tlačítko Uložit .

6. Vyberte Nastavení TLS/SSL aplikace. Vyberte certifikáty privátních klíčů (. pfx). Pomocí procesu import Key Vault certifikátu importujte Identity podpisový certifikát tokenu serveru s podepsaným držitelem.

7. nakonfigurujte aplikaci tak, aby používala podpisový certifikát tokenu na základě vašeho výběru hostitelského operačního systému, a to buď Windows App Service nebo Linux App Service:

   Windows App Service

   v Visual Studio otevřete soubor nastavení aplikace projektu serveru ( appsettings.json nebo appsettings.Production.json ). V Identity konfiguraci serveru přidejte následující Key část. Zadejte Předmět certifikátu podepsaného svým držitelem pro Name klíč. V následujícím příkladu je běžný název certifikátu přiřazený v trezoru klíčů IdentityServerSigning , což má za následek CN=IdentityServerSigning :

   "IdentityServer": {
   
     ...
   
     "Key": {
       "Type": "Store",
       "StoreName": "My",
       "StoreLocation": "CurrentUser",
       "Name": "CN=IdentityServerSigning"
     }
   },
   

   pokud řešení potíží s načtením certifikátu v Windows App Service, spusťte v prostředí příkazového řádku powershellu Azure Portal Kudu následující příkaz. Příkaz zobrazí seznam certifikátů, ke kterým může aplikace přistupovat z CurrentUser > My úložiště certifikátů. Výstup zahrnuje předměty certifikátů a kryptografické otisky užitečné při ladění aplikace:

   Get-ChildItem -path Cert:\CurrentUser\My -Recurse | Format-List DnsNameList, Subject, Thumbprint, EnhancedKeyUsageList
   

   App Service pro Linux

   Linux nemůže použít úložiště certifikátů Windows k načtení certifikátu TLS. V App Service pro Linux jsou certifikáty umístěny v cestě /var/ssl/private/ . Ručně načtěte a použijte certifikát z předchozí cesty.

   Pokud následující obory názvů nejsou v horní části Startup.cs projektu serveru již přítomny, přidejte je do souboru:

   using System;
   using System.IO;
   using System.Security.Cryptography.X509Certificates;
   

   V nástroji Startup.ConfigureServices aktualizujte Identity konfiguraci serveru tak, aby používala ručně načtený certifikát. V následujícím příkladu {THUMBPRINT} je zástupný otisk certifikátu:

   var certPath = "/var/ssl/private/{THUMBPRINT}.p12";
   
   if (File.Exists(certPath))
   {
       var bytes = File.ReadAllBytes(certPath);
       var certificate = new X509Certificate2(bytes);
   
       services.AddIdentityServer()
           .AddApiAuthorization<ApplicationUser, ApplicationDbContext>(options => { })
           .AddSigningCredential(certificate);
   }
   else
   {
       throw new FileNotFoundException($"Certificate path: {certPath}.");
   }
   

8. v Visual Studio vytvořte Azure App Service publikační profil pro serverový projekt. v řádku nabídek vyberte: sestavit > publikovat > novou službu > Azure > Azure App Service (Windows nebo Linux). když je Visual Studio připojená k předplatnému azure, můžete si nastavit zobrazení prostředků Azure podle typu prostředku. Přejděte v seznamu webové aplikace , vyhledejte App Service pro aplikaci a vyberte ji. Vyberte Dokončit.

9. když se Visual Studio vrátí do okna publikovat , automaticky se zjistí závislosti klíčů a služby SQL Server database.

   Pro službu trezoru klíčů se nevyžadují žádné změny konfigurace výchozích nastavení.

   Pro účely testování je možné nasadit místní databázi SQLite aplikace, která je nakonfigurovaná ve výchozím nastavení Blazor šablonou, a to bez další konfigurace. Konfigurace jiné databáze pro Identity Server v produkčním prostředí je mimo rámec tohoto článku. Další informace najdete v tématu prostředky databáze v následujících sadách dokumentace:

   • App Service
   • Identity WebServer

10. Publikujte aplikaci. Visual Studio otevře okno prohlížeče a požádá o web.

Dokumentace k Azure obsahuje další podrobnosti o používání služeb Azure. Podívejte se na následující zdroje informací:

• Dokumentace k App Service
• Azure Key Vault

Pro každý testovací běh aplikace po změně aplikace, konfigurace aplikace nebo služeb Azure v Azure Portal doporučujeme použít nové soukromé nebo anonymním okno prohlížeče. cookiePři záchodu s z předchozího testovacího běhu může dojít k selhání ověřování nebo autorizaci při testování lokality i v případě, že je Konfigurace lokality správná. další informace o tom, jak nakonfigurovat Visual Studio pro otevření nového okna prohlížeče v privátním nebo anonymním pro každý testovací běh, najdete v části Cookie s a daty webu .

Když se v Azure Portal změní konfigurace App Service, obecně se tyto aktualizace projeví rychleji, ale ne okamžitě. V některých případech je třeba počkat krátce App Service restartováním, aby se změna konfigurace projevila.

Použití vlastního certifikátu domény a TLS pro komunikaci protokolu HTTPS v Azure App Service

Pokyny v této části vysvětlují, jak vytvořit a používat certifikát TLS pro komunikaci protokolu HTTPS s prohlížeči pro aplikaci, která je nasazená do Azure App Service. I když se pokyny týkají použití certifikátu s vlastní doménou, doprovodné materiály jsou stejně použitelné pro použití výchozí domény aplikací Azure, například contoso.azurewebsites.net .

Konfigurace aplikace, Azure App Service a Azure Key Vault pro hostování s vlastní doménou a HTTPS:

1. Použijte plán App Service s úrovní plánu Basic B1 nebo vyšší. App Service vyžaduje, Basic B1 aby úroveň služby nebo vyšší používala vlastní domény.

2. Vytvořte certifikát PFX pro komunikaci zabezpečeného prohlížeče (protokol HTTPS) lokality s běžným názvem plně kvalifikovaného názvu domény (FQDN) webu, který vaše organizace řídí (například www.contoso.com ). Vytvořte certifikát pomocí:

   • Použití klíče
     • Ověření digitálního podpisu ( digitalSignature )
     • Šifrování klíče ( keyEncipherment )
   • Rozšířené/rozšířené použití klíče
     • Ověřování klientů (1.3.6.1.5.5.7.3.2)
     • Ověřování serveru (1.3.6.1.5.5.7.3.1)

   Chcete-li vytvořit certifikát, použijte jeden z následujících přístupů nebo jakýkoli jiný vhodný nástroj nebo online službu:

   • Azure Key Vault
   • MakeCert pro Windows
   • OpenSSL

   Poznamenejte si heslo, které se použije později k importu certifikátu do Azure Key Vault.

   Další informace o Azure Key Vaultch certifikátech najdete v článku Azure Key Vault: certifikáty.

3. Vytvořte novou Azure Key Vault nebo použijte existující Trezor klíčů v předplatném Azure.

4. V oblasti certifikáty trezoru klíčů importujte certifikát webu PFX. Poznamenejte si kryptografický otisk certifikátu, který se v konfiguraci aplikace používá později.

5. V Azure App Service v Azure Portal pro skladovou položku a velikost potvrďte, že úroveň App Service je Basic B1 nebo vyšší. App Service vyžaduje, Basic B1 aby úroveň služby nebo vyšší používala vlastní domény.

6. Otevřete konfiguraci aplikace v App Service a přidejte nové nastavení aplikace s klíčem WEBSITE_LOAD_CERTIFICATES (Pokud ještě neexistuje) nebo upravte existující WEBSITE_LOAD_CERTIFICATES nastavení aplikace. Zadejte kryptografický otisk certifikátu TLS zaznamenaného dříve:

   • Při použití automatického podepisování tokenů je pro komunikaci pomocí protokolu HTTPS k dispozici pouze jeden kryptografický otisk. Příklad klíče: WEBSITE_LOAD_CERTIFICATES Příklad hodnoty: 57443A552A46DB...D55E28D412B943565
   • Při použití samostatného podpisového certifikátu tokenu existují dva kryptografické otisky pro nastavení s hodnotami kryptografických otisků oddělenými čárkou. Příklad klíče: WEBSITE_LOAD_CERTIFICATES Příklad hodnoty: 57443A552A46DB...D55E28D412B943565,29F43A772CB6AF...1D04F0C67F85FB0B1

   V Azure Portal je ukládání nastavení aplikace dvoustupňový proces: uložte WEBSITE_LOAD_CERTIFICATES nastavení klíč-hodnota a potom v horní části okna vyberte tlačítko Uložit .

7. Vyberte Nastavení TLS/SSL aplikace. Vyberte certifikáty privátních klíčů (. pfx). Pomocí procesu import Key Vault certifikátu importujte certifikát webu pro komunikaci pomocí protokolu HTTPS.

8. Přejděte do okna vlastní domény . Na webu vašeho doménového registrátora nakonfigurujte doménu pomocí IP adresy a ID ověření vlastní domény . Typická konfigurace domény zahrnuje:

   • Záznam a s hostitelem @ a hodnotou IP adresy z Azure Portal.
   • Záznam TXT s hostitelem asuid a hodnotou identifikátoru ověřování vygenerovaných Azure a poskytovaný Azure Portal.

   Ujistěte se, že jste změny uložili na webu vašeho registrátora domény správně. Některé weby registrátora vyžadují dvoustupňový proces ukládání záznamů v doméně: jeden nebo více záznamů se ukládá jednotlivě a pomocí samostatného tlačítka aktualizují registraci domény.

9. Vraťte se do okna vlastní domény v Azure Portal. Vyberte Přidat vlastní doménu. Vyberte možnost záznam A . Zadejte doménu a vyberte ověřit. Pokud jsou záznamy v doméně správné a šířené přes Internet, portál vám umožní vybrat tlačítko Přidat vlastní doménu .

   Může trvat několik dní, než se změny v registraci domény šíří v rámci služby DNS (Internet Domain Name Server) po jejich zpracování doménovým registrátorem. Pokud se záznamy v doméně během tří pracovních dnů neaktualizují, potvrďte, že záznamy jsou správně nastavené s doménovým registrátorem, a obraťte se na zákaznickou podporu.

10. V okně vlastní domény je stav protokolu SSL pro danou doménu označený Not Secure . Vyberte odkaz Přidat vazbu . Vyberte certifikát HTTPS lokality z trezoru klíčů pro vlastní doménovou vazbu.

Dokumentace k Azure obsahuje další podrobnosti o používání služeb Azure a vlastních domén s vazbou TLS v App Service, včetně informací o použití záznamů CNAME namísto záznamů. Další informace naleznete v následujících zdrojích:

• Dokumentace k App Service
• Kurz: Mapování existujícího vlastního názvu DNS na službu Azure App Service
• Zabezpečení vlastního názvu DNS s vazbou TLS/SSL v Azure App Service
• Azure Key Vault

Pro každý testovací běh aplikace po změně aplikace, konfigurace aplikace nebo služeb Azure v Azure Portal doporučujeme použít nové soukromé nebo anonymním okno prohlížeče. cookiePři záchodu s z předchozího testovacího běhu může dojít k selhání ověřování nebo autorizaci při testování lokality i v případě, že je Konfigurace lokality správná. další informace o tom, jak nakonfigurovat Visual Studio pro otevření nového okna prohlížeče v privátním nebo anonymním pro každý testovací běh, najdete v části Cookie s a daty webu .

Když se v Azure Portal změní konfigurace App Service, obecně se tyto aktualizace projeví rychleji, ale ne okamžitě. V některých případech je třeba počkat krátce App Service restartováním, aby se změna konfigurace projevila.

pokud řešení potíží s načtením certifikátu v Windows App Service, spusťte v prostředí příkazového řádku powershellu Azure Portal Kudu následující příkaz. Příkaz zobrazí seznam certifikátů, ke kterým může aplikace přistupovat z CurrentUser > My úložiště certifikátů. Výstup zahrnuje předměty certifikátů a kryptografické otisky užitečné při ladění aplikace:

Get-ChildItem -path Cert:\CurrentUser\My -Recurse | Format-List DnsNameList, Subject, Thumbprint, EnhancedKeyUsageList

Řešení potíží

Běžné chyby

• Chybné konfigurace aplikace nebo Identity zprostředkovatele (IP)

  Nejčastější chyby jsou způsobené nesprávnou konfigurací. Tady je několik příkladů:

  • V závislosti na požadavcích scénáře brání chybějící nebo nesprávná autorita, instance, ID tenanta, doména tenanta, ID klienta nebo identifikátor URI přesměrování aplikaci v ověřování klientů.
  • Nesprávný obor přístupového tokenu brání klientům v přístupu ke koncovým bodům webového rozhraní API serveru.
  • Nesprávná nebo chybějící oprávnění rozhraní API serveru brání klientům v přístupu ke koncovým bodům webového rozhraní API serveru.
  • Spuštění aplikace na jiném portu, než je nakonfigurované v identifikátoru URI přesměrování Identity registrace aplikace poskytovatele.

  V částech s pokyny pro konfiguraci najdete příklady správné konfigurace. Pečlivě zkontrolujte každou část článku a zkontrolujte chybné konfigurace aplikace a IP adresy.

  Pokud se konfigurace zdá být správná:

  • Analýza aplikačních protokolů

  • Prozkoumejte síťový provoz mezi klientskou aplikací a IP adresou nebo serverovou aplikací pomocí vývojářských nástrojů prohlížeče. Ip adresa nebo serverová aplikace často vrátí klientovi přesnou chybovou zprávu nebo zprávu s vodítkem k příčině problému. Vývojářské nástroje najdete v následujících článcích:

    • Google Chrome (dokumentace Google)
    • Microsoft Edge
    • Mozilla Firefox (dokumentace Mozilla)

  • Dekódujte obsah souboru JWT (JSON Web Token), který se používá k ověřování klienta nebo přístupu k webovému rozhraní API serveru v závislosti na tom, kde k problému dochází. Další informace najdete v tématu Kontrola obsahu souboru JSON WEB TOKEN (JWT).

  Dokumentační tým reaguje na zpětnou vazbu k dokumentům a chyby v článcích (otevřete problém v části Tato zpětná vazba na stránce), ale nemůže poskytovat podporu k produktům. Při řešení potíží s aplikací je k dispozici několik veřejných fór podpory. Doporučujeme postupovat následovně:

  • Stack Overflow (značka: blazor )
  • ASP.NET Core Slack Team
  • Blazor Gitter

  Předchozí fóra nejsou vlastněna ani řízena společností Microsoft.

  V případě zpráv o chybách architektury bez zabezpečení, bez citlivosti a bez důvěrných reprodukovatelných architektur otevřete problém v ASP.NET Core produktové jednotce. Neotevřete problém s produktovou jednotkou, dokud pečlivě neprošetříte příčinu problému a nemůžete ho vyřešit sami a s pomocí komunity na veřejném fóru podpory. Produktová jednotka nemůže řešit potíže s jednotlivými aplikacemi, které jsou poškozené kvůli jednoduché chybné konfiguraci nebo případům použití zahrnujícím služby třetích stran. Pokud je sestava citlivá nebo důvěrná nebo popisuje potenciální chybu zabezpečení v produktu, kterou mohou útočníci zneužít, podívejte se na téma Hlášení problémů a chyb zabezpečení (dotnet/aspnetcore GitHub úložiště).

• Neautorizovaný klient pro AAD

  info: Microsoft.AspNetCore.Authorization.DefaultAuthorizationService[2] Autorizace se nezdařila. Tyto požadavky nebyly splněny: DenyAnonymousAuthorizationRequirement: Vyžaduje ověřeného uživatele.

  Chyba zpětného volání přihlášení z AAD:

  • Chyba: unauthorized_client
  • Popis: AADB2C90058: The provided application is not configured to allow public clients.

  Řešení chyby:

  1. V Azure Portal přístup k manifestu aplikace.
  2. Nastavte allowPublicClient atribut na null nebo true .

Cookies a data lokality

CookieData webů a se mohou uchovat napříč aktualizacemi aplikací a interferovat s testováním a řešením potíží. Při provádění změn kódu aplikace, změn uživatelského účtu u poskytovatele nebo změn konfigurace aplikace zprostředkovatele vymažte následující:

• Přihlášení cookie uživatele
• Aplikace cookie
• Uložená data lokality a uložená v mezipaměti

Jedním z přístupů, jak zabránit tomu, aby se při testování a řešení potíží přerušují cookie data lokality, je:

• Konfigurace prohlížeče
  • Pro testování použijte prohlížeč, který můžete nakonfigurovat tak, aby při každém zavření prohlížeče odstranil všechna data a cookie data webu.
  • Ujistěte se, že je prohlížeč ručně zavřen nebo integrované vývojové prostředí (IDE) kvůli jakékoli změně konfigurace aplikace, testovacího uživatele nebo zprostředkovatele.
• Pomocí vlastního příkazu otevřete prohlížeč v anonymním nebo privátním režimu v Visual Studio:
  • V dialogovém okně Procházet Visual Studio tlačítko Spustit.
  • Vyberte tlačítko Přidat.
  • Do pole Program zadejte cestu k prohlížeči. Následující spustitelné cesty jsou typická umístění instalace pro Windows 10. Pokud je váš prohlížeč nainstalovaný na jiném místě nebo pokud ho Windows 10, zadejte cestu ke spustitelnému souboru prohlížeče.
    • Microsoft Edge:C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
    • Google Chrome: C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
    • Mozilla Firefox: C:\Program Files\Mozilla Firefox\firefox.exe
  • Do pole Argumenty zadejte možnost příkazového řádku, kterou prohlížeč používá k otevření v anonymním nebo privátním režimu. Některé prohlížeče vyžadují adresu URL aplikace.
    • Microsoft Edge: Použijte -inprivate .
    • Google Chrome: Použijte --incognito --new-window {URL} , kde zástupný symbol je adresa URL, která se má otevřít {URL} (například https://localhost:5001 ).
    • Mozilla Firefox: Použijte -private -url {URL} , kde zástupný symbol je adresa URL, která se má otevřít {URL} (například https://localhost:5001 ).
  • Do pole Popisný název zadejte název. Například, Firefox Auth Testing.
  • Vyberte tlačítko OK.
  • Pokud se chcete vyhnout výběru profilu prohlížeče pro každou iteraci testování pomocí aplikace, nastavte profil jako výchozí pomocí tlačítka Nastavit jako výchozí.
  • Ujistěte se, že integrované vývojové prostředí zavře prohlížeč kvůli jakékoli změně konfigurace aplikace, testovacího uživatele nebo zprostředkovatele.

Upgrady aplikací

Funkční aplikace může selhat okamžitě po upgradu .NET Core SDK na vývojovém počítači nebo změně verzí balíčků v rámci aplikace. V některých případech může při provádění významných upgradů dojít k přerušení aplikace v neschválených balíčcích. Většinu těchto problémů můžete vyřešit pomocí těchto pokynů:

1. Vymažte mezipaměť balíčků NuGet systému spuštěním příkazu dotnet nuget locals all --clear z příkazového prostředí.
2. Odstraňte složky a bin obj projektu.
3. Obnovte a znovu sestavte projekt.
4. Před znovunasazování aplikace odstraňte všechny soubory ve složce nasazení na serveru.

Spuštění aplikace Server

Při testování hostovaného řešení a řešení souvisejících potíží se ujistěte, že aplikaci používáte Blazor z Server projektu. Například v Visual Studio před zahájením aplikace potvrďte, že je projekt Server zvýrazněný v Průzkumník řešení, a to pomocí libovolného z následujících přístupů:

• Vyberte tlačítko Run (Spustit).
• V nabídce > použijte Ladění spustit ladění.
• Stiskněte klávesu F5.

Kontrola obsahu souboru JSON Web Token (JWT)

Pokud chcete dekódovat JSON Web Token (JWT), použijte nástroj jwt.ms Microsoftu. Hodnoty v uživatelském rozhraní nikdy neopustí váš prohlížeč.

Příklad kódovaného JWT (zkráceně pro zobrazení):

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIsImtpZCI6Ilg1ZVhrNHh5b2pORnVtMWtsMll0djhkbE5QNC1j... bQdHBHGcQQRbW7Wmo6SWYG4V_bU55Ug_PW4pLPr20tTS8Ct7_uwy9DWrzCMzpD-EiwT5IjXwlGX3IXVjHIlX50IVIydBoPQtadvT7saKo1G5Jmutgq41o-dmz6-yBMKV2_nXA25Q

Příklad JWT dekódovaný nástrojem pro aplikaci, která se ověřuje vůči Azure AAD B2C:

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "X5eXk4xyojNFum1kl2Ytv8dlNP4-c57dO6QGTVBwaNk"
}.{
  "exp": 1610059429,
  "nbf": 1610055829,
  "ver": "1.0",
  "iss": "https://mysiteb2c.b2clogin.com/5cc15ea8-a296-4aa3-97e4-226dcc9ad298/v2.0/",
  "sub": "5ee963fb-24d6-4d72-a1b6-889c6e2c7438",
  "aud": "70bde375-fce3-4b82-984a-b247d823a03f",
  "nonce": "b2641f54-8dc4-42ca-97ea-7f12ff4af871",
  "iat": 1610055829,
  "auth_time": 1610055822,
  "idp": "idp.com",
  "tfp": "B2C_1_signupsignin"
}.[Signature]

Další zdroje informací

• Nasazení do Azure App Service
• Import certifikátu z Key Vault (dokumentace k Azure)
• Blazor WebAssemblyASP.NET Core další scénáře zabezpečení
• Neověřené nebo neautorizované požadavky webového rozhraní API v aplikaci s zabezpečeným výchozím klientem
• Konfigurace ASP.NET Core pro práci s proxy servery a nástroji pro vyrovnávání zatížení: Obsahuje pokyny pro:
  • Použití middlewaru předávaných hlaviček k uchování informací o schématu protokolu HTTPS napříč proxy servery a interními sítěmi.
  • Další scénáře a případy použití, včetně konfigurace ručního schématu, změn cest požadavků pro správné směrování požadavků a předávání schématu požadavků pro reverzní proxy servery se systémem Linux a non-IIS.

Tento článek vysvětluje, jak vytvořit hostované Blazor WebAssembly řešení , které používá Identity Server k ověřování uživatelů a volání rozhraní API.

dotnet new blazorwasm -au Individual -ho -o {APP NAME}

Server Konfigurace aplikace

Následující části popisují přidání do projektu, pokud je zahrnutá Podpora ověřování.

Spouštěcí třída

StartupTřída obsahuje následující doplňky.

• V Startup.ConfigureServices:

  • ASP.NET Core Identity:

    services.AddDbContext<ApplicationDbContext>(options =>
        options.UseSqlite(
            Configuration.GetConnectionString("DefaultConnection")));
    
    services.AddDefaultIdentity<ApplicationUser>(options => 
            options.SignIn.RequireConfirmedAccount = true)
        .AddEntityFrameworkStores<ApplicationDbContext>();
    

  • Identityserver s další AddApiAuthorization pomocnou metodou, která nastaví výchozí konvence ASP.NET Core na Identity serveru:

    services.AddIdentityServer()
        .AddApiAuthorization<ApplicationUser, ApplicationDbContext>();
    

  • Ověřování s další AddIdentityServerJwt pomocnou metodou, která nakonfiguruje aplikaci k ověření tokenů JWT vyprodukovaných Identity serverem:

    services.AddAuthentication()
        .AddIdentityServerJwt();
    

• V Startup.Configure:

  • Identitymiddleware serveru zpřístupňuje koncové body OpenID Připojení (OIDC):

    app.UseIdentityServer();
    

  • Middleware ověřování zodpovídá za ověření přihlašovacích údajů požadavku a nastavení uživatele v kontextu požadavku:

    app.UseAuthentication();
    

  • Middleware autorizace povoluje možnosti autorizace:

    app.UseAuthorization();
    

Azure App Service v systému Linux

Určete explicitně vystavitele při nasazení do Azure App Service v systému Linux. Další informace naleznete v tématu Úvod do ověřování pro jedno stránkové aplikace v ASP.NET Core.

AddApiAuthorization

AddApiAuthorizationpomocná metoda konfiguruje Identity Server pro ASP.NET Core scénáře. IdentityServer je výkonné a rozšiřitelné rozhraní pro zpracování otázek zabezpečení aplikací. IdentityServer zveřejňuje nepotřebnou složitost pro nejběžnější scénáře. V důsledku toho je k dispozici sada konvencí a možností konfigurace, které považujeme za dobrý výchozí bod. Jakmile se vaše potřeby ověřování změní, Identity je k dispozici plná síla serveru pro přizpůsobení ověřování podle požadavků aplikace.

Přidat Identity ServerJwt

AddIdentityServerJwtPomocná metoda nakonfiguruje schéma zásad pro aplikaci jako výchozí obslužnou rutinu ověřování. Zásady jsou nakonfigurovány tak, aby umožňovaly Identity zpracování všech požadavků směrovaných na jakoukoli dílčí cestu v Identity prostoru URL /Identity . JwtBearerHandlerZpracovává všechny ostatní požadavky. Tato metoda navíc:

• Zaregistruje {APPLICATION NAME}API prostředek rozhraní API se Identity serverem s výchozím oborem {APPLICATION NAME}API .
• Konfiguruje middleware tokenu JWT nosiče k ověření tokenů vydaných Identity serverem pro aplikaci.

WeatherForecastController

V rozhraní WeatherForecastController ( Controllers/WeatherForecastController.cs ) je [Authorize] atribut použit pro třídu. Atribut označuje, že uživatel musí být autorizovaný na základě výchozích zásad pro přístup k prostředku. Výchozí zásada autorizace je nakonfigurovaná tak, aby používala výchozí schéma ověřování, které je nastavené nástrojem AddIdentityServerJwt . Pomocná metoda se konfiguruje JwtBearerHandler jako výchozí obslužná rutina pro požadavky na aplikaci.

ApplicationDbContext

V rozhraní ApplicationDbContext ( Data/ApplicationDbContext.cs ) se DbContext rozšiřuje ApiAuthorizationDbContext<TUser> na zahrnutí schématu pro Identity Server. ApiAuthorizationDbContext<TUser> je odvozen z IdentityDbContext .

Chcete-li získat úplné řízení schématu databáze, zdědit jednu z dostupných Identity DbContext tříd a nakonfigurovat kontext pro zahrnutí Identity schématu voláním builder.ConfigurePersistedGrantContext(_operationalStoreOptions.Value) v OnModelCreating metodě.

OidcConfigurationController

V rozhraní OidcConfigurationController ( Controllers/OidcConfigurationController.cs ) se koncový bod klienta zřídí pro poskytování OIDC parametrů.

Nastavení aplikace

V souboru nastavení aplikace ( appsettings.json ) v kořenovém adresáři projektu IdentityServer obsahuje část seznam konfigurovaných klientů. V následujícím příkladu je jeden klient. Název klienta odpovídá názvu aplikace a je mapován podle konvence na ClientId parametr OAuth. Profil indikuje typ aplikace, která se konfiguruje. Profil se interně používá k tomu, aby bylo možné řídit konvence, které zjednodušují proces konfigurace serveru.

"IdentityServer": {
  "Clients": {
    "{APP ASSEMBLY}.Client": {
      "Profile": "IdentityServerSPA"
    }
  }
}

Zástupný symbol {APP ASSEMBLY} je název sestavení aplikace (například BlazorSample.Client ).

Client Konfigurace aplikace

Ověřovací balíček

Když je aplikace vytvořená tak, aby používala jednotlivé uživatelské účty ( Individual ), aplikace automaticky obdrží odkaz na balíček Microsoft.AspNetCore.Components.WebAssembly.Authentication v souboru projektu aplikace. Balíček poskytuje sadu primitivních elementů, které aplikaci pomůžou ověřit uživatele a získat tokeny pro volání chráněných rozhraní API.

Pokud se do aplikace přidává ověřování, přidejte balíček do souboru projektu aplikace ručně:

<PackageReference 
  Include="Microsoft.AspNetCore.Components.WebAssembly.Authentication" 
  Version="{VERSION}" />

pro zástupný text je k {VERSION} dispozici nejnovější stabilní verze balíčku, která odpovídá verzi sdílené architektury aplikace, v historii verzí balíčku na adrese NuGet. org.

HttpClient rozšířeného

V aplikaci Program.cs je pojmenovaná HttpClient ( {APP ASSEMBLY}.ServerAPI ) nakonfigurovaná tak, aby poskytovala HttpClient instance, které zahrnují přístupové tokeny při vytváření žádostí na rozhraní API serveru:

builder.Services.AddHttpClient("{APP ASSEMBLY}.ServerAPI", 
        client => client.BaseAddress = new Uri(builder.HostEnvironment.BaseAddress))
    .AddHttpMessageHandler<BaseAddressAuthorizationMessageHandler>();

builder.Services.AddScoped(sp => sp.GetRequiredService<IHttpClientFactory>()
    .CreateClient("{APP ASSEMBLY}.ServerAPI"));

Zástupný symbol {APP ASSEMBLY} je název sestavení aplikace (například BlazorSample.Client ).

Podpora autorizace rozhraní API

Podpora ověřování uživatelů je zapojena do kontejneru služby prostřednictvím metody rozšíření poskytované v rámci Microsoft.AspNetCore.Components.WebAssembly.Authentication balíčku. Tato metoda nastaví služby, které aplikace požaduje, aby spolupracovaly se stávajícím autorizačním systémem.

builder.Services.AddApiAuthorization();

Ve výchozím nastavení je konfigurace pro aplikaci načtena podle konvence z _configuration/{client-id} . Podle konvence je ID klienta nastaveno na název sestavení aplikace. Tato adresa URL může být změněna tak, aby odkazovala na samostatný koncový bod voláním přetížení s možnostmi.

Importovat soubor

Obor Microsoft.AspNetCore.Components.Authorization názvů je k dispozici v celé aplikaci prostřednictvím souboru _Imports.razor :

@using System.Net.Http
@using System.Net.Http.Json
@using Microsoft.AspNetCore.Components.Authorization
@using Microsoft.AspNetCore.Components.Forms
@using Microsoft.AspNetCore.Components.Routing
@using Microsoft.AspNetCore.Components.Web
@using Microsoft.AspNetCore.Components.Web.Virtualization
@using Microsoft.AspNetCore.Components.WebAssembly.Http
@using Microsoft.JSInterop
@using {APPLICATION ASSEMBLY}.Client
@using {APPLICATION ASSEMBLY}.Client.Shared

Indexová stránka

Stránka Index wwwroot/index.html (Index) obsahuje skript, který definuje v AuthenticationService JavaScriptu. AuthenticationService zpracovává podrobnosti nízké úrovně protokolu OIDC. Aplikace interně volá metody definované ve skriptu k provedení ověřovacích operací.

<script src="_content/Microsoft.AspNetCore.Components.WebAssembly.Authentication/
    AuthenticationService.js"></script>

Součást aplikace

AppSoučást ( App.razor ) je podobná App komponentě, kterou najdete v Blazor Server aplikacích:

• Komponenta spravuje vystavení CascadingAuthenticationState AuthenticationState do zbytku aplikace.
• AuthorizeRouteViewKomponenta zajistí, že aktuální uživatel má oprávnění pro přístup k dané stránce nebo jinak vykreslí RedirectToLogin součást.
• RedirectToLoginKomponenta spravuje přesměrování neautorizovaných uživatelů na přihlašovací stránku.

v důsledku změn v rozhraní napříč verzemi ASP.NET Core se Razor App App.razor v této části nezobrazí značka pro komponentu (). Chcete-li zkontrolovat označení komponenty pro danou verzi, použijte některý z následujících přístupů:

• vytvořte aplikaci zřízenou pro ověřování z výchozí Blazor WebAssembly šablony projektu pro verzi ASP.NET Core, kterou chcete použít. Zkontrolujte App součást ( App.razor ) ve vygenerované aplikaci.

• Zkontrolujte App součást ( App.razor ) v referenčním zdroji.

  Poznámka

  dokumentace odkazuje na zdrojový odkaz na ASP.NET Core načtení main větve úložiště, která představuje aktuální vývoj jednotky produktu pro další verzi ASP.NET Core. Pokud chcete vybrat větev pro jinou verzi, vyberte ji pomocí rozevíracího seznamu větve přepínače nebo značky . vyberte například release/5.0 větev pro verzi ASP.NET Core 5,0.

Komponenta RedirectToLogin

RedirectToLoginSoučást ( Shared/RedirectToLogin.razor ):

• Spravuje přesměrování neautorizovaných uživatelů na přihlašovací stránku.
• Zachová aktuální adresu URL, ke které se uživatel pokouší získat přístup, aby se mohla vrátit na tuto stránku, pokud je ověření úspěšné.

@inject NavigationManager Navigation
@using Microsoft.AspNetCore.Components.WebAssembly.Authentication
@code {
    protected override void OnInitialized()
    {
        Navigation.NavigateTo(
            $"authentication/login?returnUrl={Uri.EscapeDataString(Navigation.Uri)}");
    }
}

Komponenta LoginDisplay

LoginDisplaySoučást ( Shared/LoginDisplay.razor ) je vykreslena v MainLayout komponentě ( Shared/MainLayout.razor ) a spravuje následující chování:

• Pro ověřené uživatele:
  • Zobrazí aktuální uživatelské jméno.
  • Nabízí odkaz na stránku profil uživatele v ASP.NET Core Identity .
  • Nabízí tlačítko pro odhlášení od aplikace.
• Pro anonymní uživatele:
  • Nabízí možnost registrace.
  • Nabízí možnost přihlásit se.

@using Microsoft.AspNetCore.Components.Authorization
@using Microsoft.AspNetCore.Components.WebAssembly.Authentication
@inject NavigationManager Navigation
@inject SignOutSessionStateManager SignOutManager

<AuthorizeView>
    <Authorized>
        <a href="authentication/profile">Hello, @context.User.Identity.Name!</a>
        <button class="nav-link btn btn-link" @onclick="BeginSignOut">
            Log out
        </button>
    </Authorized>
    <NotAuthorized>
        <a href="authentication/register">Register</a>
        <a href="authentication/login">Log in</a>
    </NotAuthorized>
</AuthorizeView>

@code {
    private async Task BeginSignOut(MouseEventArgs args)
    {
        await SignOutManager.SetSignOutState();
        Navigation.NavigateTo("authentication/logout");
    }
}

Ověřovací komponenta

Stránka vytvořená komponentou ( ) definuje trasy vyžadované Authentication pro zpracování různých fází Pages/Authentication.razor ověřování.

RemoteAuthenticatorViewKomponenta:

• Je poskytován Microsoft.AspNetCore.Components.WebAssembly.Authentication balíčkem .
• Spravuje provádění příslušných akcí v každé fázi ověřování.

@page "/authentication/{action}"
@using Microsoft.AspNetCore.Components.WebAssembly.Authentication

<RemoteAuthenticatorView Action="@Action" />

@code {
    [Parameter]
    public string Action { get; set; }
}

Komponenta FetchData

Tato FetchData součást ukazuje, jak:

• Zřízení přístupového tokenu
• Pomocí přístupového tokenu v serverové aplikaci zavolejte chráněné rozhraní API prostředků.

Tato @attribute [Authorize] direktiva indikuje Blazor WebAssembly autorizačnímu systému, že uživatel musí být autorizovaný, aby mohl navštívit tuto součást. Přítomnost atributu v Client aplikaci nebrání volání rozhraní API na serveru bez správných přihlašovacích údajů. Server [Authorize] K jejich správné ochraně musí aplikace také použít příslušné koncové body.

IAccessTokenProvider.RequestAccessToken postará o vyžadování přístupového tokenu, který se dá přidat do žádosti o volání rozhraní API. Pokud je token uložen v mezipaměti nebo služba může zřídit nový přístupový token bez zásahu uživatele, požadavek na token je úspěšný. V opačném případě požadavek tokenu selže s objektem AccessTokenNotAvailableException , který je zachycen v try-catch příkazu.

Aby bylo možné získat skutečný token, který se má zahrnout do žádosti, musí aplikace ověřit, jestli žádost proběhla úspěšně voláním tokenResult.TryGetToken(out var token) .

Pokud byl požadavek úspěšný, je proměnná tokenu naplněná přístupovým tokenem. AccessToken.ValueVlastnost tokenu zpřístupňuje řetězec literálu, který má být zahrnut v Authorization hlavičce požadavku.

Pokud se žádost nezdařila, protože se token nepodařilo zřídit bez zásahu uživatele, výsledek tokenu obsahuje adresu URL pro přesměrování. Když přejdete na tuto adresu URL, uživatel přejde na přihlašovací stránku a vrátí se zpátky na aktuální stránku po úspěšném ověření.

@page "/fetchdata"
@using Microsoft.AspNetCore.Authorization
@using Microsoft.AspNetCore.Components.WebAssembly.Authentication
@using {APP NAMESPACE}.Shared
@attribute [Authorize]
@inject HttpClient Http

...

@code {
    private WeatherForecast[] forecasts;

    protected override async Task OnInitializedAsync()
    {
        try
        {
            forecasts = await Http.GetFromJsonAsync<WeatherForecast[]>("WeatherForecast");
        }
        catch (AccessTokenNotAvailableException exception)
        {
            exception.Redirect();
        }
    }
}

Spuštění aplikace

Spusťte aplikaci z projektu Server. Při použití Visual Studio:

• V rozevíracím seznamu Projekty po spuštění na panelu nástrojů nastavte aplikaci Server API a vyberte tlačítko Spustit.
• Vyberte projekt Server v Průzkumník řešení a na panelu nástrojů vyberte tlačítko Spustit nebo spusťte aplikaci z nabídky Ladit.

Název a deklarace identity role s autorizací rozhraní API

Vlastní uživatelská továrna

V aplikaci Client vytvořte vlastní uživatelskou továrnu. Identity Server odešle několik rolí jako pole JSON v jedné role deklaraci identity. Jedna role se odesílá jako řetězcová hodnota v deklaraci identity. Továrna vytvoří role jednotlivou deklaraci identity pro každou z rolí uživatele.

CustomUserFactory.cs:

using System.Linq;
using System.Security.Claims;
using System.Text.Json;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Components.WebAssembly.Authentication;
using Microsoft.AspNetCore.Components.WebAssembly.Authentication.Internal;

public class CustomUserFactory
    : AccountClaimsPrincipalFactory<RemoteUserAccount>
{
    public CustomUserFactory(IAccessTokenProviderAccessor accessor)
        : base(accessor)
    {
    }

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

        if (user.Identity.IsAuthenticated)
        {
            var identity = (ClaimsIdentity)user.Identity;
            var roleClaims = identity.FindAll(identity.RoleClaimType).ToArray();

            if (roleClaims.Any())
            {
                foreach (var existingClaim in roleClaims)
                {
                    identity.RemoveClaim(existingClaim);
                }

                var rolesElem = account.AdditionalProperties[identity.RoleClaimType];

                if (rolesElem is JsonElement roles)
                {
                    if (roles.ValueKind == JsonValueKind.Array)
                    {
                        foreach (var role in roles.EnumerateArray())
                        {
                            identity.AddClaim(new Claim(options.RoleClaim, role.GetString()));
                        }
                    }
                    else
                    {
                        identity.AddClaim(new Claim(options.RoleClaim, roles.GetString()));
                    }
                }
            }
        }

        return user;
    }
}

V aplikaci Client zaregistrujte továrnu v Program.cs :

builder.Services.AddApiAuthorization()
    .AddAccountClaimsPrincipalFactory<CustomUserFactory>();

V aplikaci Server zavolejte tvůrce, AddRoles který přidá služby související s Identity rolemi:

using Microsoft.AspNetCore.Identity;

...

services.AddDefaultIdentity<ApplicationUser>(options => 
    options.SignIn.RequireConfirmedAccount = true)
    .AddRoles<IdentityRole>()
    .AddEntityFrameworkStores<ApplicationDbContext>();

Konfigurace Identity serveru

Použijte jeden z následujících přístupů:

• Možnosti autorizace rozhraní API
• Profilová služba

Možnosti autorizace rozhraní API

V Server aplikaci:

• Nakonfigurujte Identity Server tak, aby se deklarace identity a name vložily do role tokenu ID a přístupového tokenu.
• Zabraňte výchozímu mapování rolí v obslužné rutině tokenu JWT.

using System.IdentityModel.Tokens.Jwt;
using System.Linq;

...

services.AddIdentityServer()
    .AddApiAuthorization<ApplicationUser, ApplicationDbContext>(options => {
        options.IdentityResources["openid"].UserClaims.Add("name");
        options.ApiResources.Single().UserClaims.Add("name");
        options.IdentityResources["openid"].UserClaims.Add("role");
        options.ApiResources.Single().UserClaims.Add("role");
    });

JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Remove("role");

Profilová služba

V Server aplikaci vytvořte ProfileService implementaci.

ProfileService.cs:

using IdentityModel;
using IdentityServer4.Models;
using IdentityServer4.Services;
using System.Threading.Tasks;

public class ProfileService : IProfileService
{
    public ProfileService()
    {
    }

    public async Task GetProfileDataAsync(ProfileDataRequestContext context)
    {
        var nameClaim = context.Subject.FindAll(JwtClaimTypes.Name);
        context.IssuedClaims.AddRange(nameClaim);

        var roleClaims = context.Subject.FindAll(JwtClaimTypes.Role);
        context.IssuedClaims.AddRange(roleClaims);

        await Task.CompletedTask;
    }

    public async Task IsActiveAsync(IsActiveContext context)
    {
        await Task.CompletedTask;
    }
}

V aplikaci Server zaregistrujte službu profilu v Startup.ConfigureServices :

using IdentityServer4.Services;

...

services.AddTransient<IProfileService, ProfileService>();

JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Remove("role");

Použití autorizačních mechanismů

V aplikaci jsou v tuto chvíli funkční Client přístupy k autorizaci komponent. Jakýkoli z autorizačních mechanismů v komponentách může k autorizaci uživatele použít roli:

• AuthorizeView component (příklad: <AuthorizeView Roles="admin"> )

• [Authorize] attribute – direktiva ( AuthorizeAttribute ) (Příklad: @attribute [Authorize(Roles = "admin")] )

• Procedurální logika (příklad: if (user.IsInRole("admin")) { ... } )

  Podporuje se více testů rolí:

  if (user.IsInRole("admin") && user.IsInRole("developer"))
  {
      ...
  }
  

User.Identity.Name se v aplikaci naplní uživatelským jménem uživatele, což je obvykle Client přihlašovací e-mailová adresa.

UserManager a SignInManager

Nastavte typ deklarace identity identifikátoru uživatele, když serverová aplikace vyžaduje:

• UserManager<TUser> nebo SignInManager<TUser> v koncovém bodu rozhraní API.
• IdentityUser podrobnosti, jako je jméno uživatele, e-mailová adresa nebo koncový čas uzamčení.

In Program.cs pro ASP.NET Core 6.0 nebo novější:

using System.Security.Claims;

...

builder.Services.Configure<IdentityOptions>(options => 
    options.ClaimsIdentity.UserIdClaimType = ClaimTypes.NameIdentifier);

Ve Startup.ConfigureServices verzi ASP.NET Core starší než 6.0:

using System.Security.Claims;

...

services.Configure<IdentityOptions>(options => 
    options.ClaimsIdentity.UserIdClaimType = ClaimTypes.NameIdentifier);

Následující kód WeatherForecastController UserName protokoluje, kdy Get je volána metoda :

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Identity;
using Microsoft.Extensions.Logging;
using {APP NAMESPACE}.Server.Models;
using {APP NAMESPACE}.Shared;

namespace {APP NAMESPACE}.Server.Controllers
{
    [Authorize]
    [ApiController]
    [Route("[controller]")]
    public class WeatherForecastController : ControllerBase
    {
        private readonly UserManager<ApplicationUser> userManager;

        private static readonly string[] Summaries = new[]
        {
            "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", 
            "Balmy", "Hot", "Sweltering", "Scorching"
        };

        private readonly ILogger<WeatherForecastController> logger;

        public WeatherForecastController(ILogger<WeatherForecastController> logger, 
            UserManager<ApplicationUser> userManager)
        {
            this.logger = logger;
            this.userManager = userManager;
        }

        [HttpGet]
        public async Task<IEnumerable<WeatherForecast>> Get()
        {
            var rng = new Random();

            var user = await userManager.GetUserAsync(User);

            if (user != null)
            {
                logger.LogInformation($"User.Identity.Name: {user.UserName}");
            }

            return Enumerable.Range(1, 5).Select(index => new WeatherForecast
            {
                Date = DateTime.Now.AddDays(index),
                TemperatureC = rng.Next(-20, 55),
                Summary = Summaries[rng.Next(Summaries.Length)]
            })
            .ToArray();
        }
    }
}

Hostování v Azure App Service s vlastní doménou a certifikátem

Následující pokyny vysvětlují:

• Postup nasazení hostované Blazor WebAssembly aplikace se Identity Serverem pro Azure App Service s vlastní doménou
• Jak vytvořit a používat certifikát TLS pro komunikaci protokolu HTTPS s prohlížeči. Přestože se pokyny zaměřují na používání certifikátu s vlastní doménou, pokyny platí stejně pro použití výchozí domény Azure Apps, například contoso.azurewebsites.net .

V tomto scénáři hostování nepoužívejte stejný certifikát pro podpisový Identity klíč tokenu serveru a zabezpečenou komunikaci HTTPS webu s prohlížeči:

• Použití různých certifikátů pro tyto dva požadavky je dobrým postupem zabezpečení, protože izoluje privátní klíče pro každý účel.
• Certifikáty TLS pro komunikaci s prohlížeči se spravují nezávisle, aniž by to ovlivnilo podepisování Identity tokenů serveru.
• Když Azure Key Vault do aplikace App Service certifikát pro vlastní vazbu domény, server nemůže získat stejný certifikát z Azure Key Vault pro Identity podepisování tokenů. Přestože je možné nakonfigurovat server tak, aby ve fyzické cestě používá stejný certifikát TLS, umístění certifikátů zabezpečení do správy zdrojového kódu je špatným postupem a ve většině scénářů byste se jim měli Identity vyhnout.

V následujících pokynech se certifikát podepsaný svým držitelem vytvoří v Azure Key Vault výhradně pro podepisování Identity tokenu serveru. Konfigurace Identity serveru používá certifikát trezoru klíčů prostřednictvím úložiště certifikátů CurrentUser > My aplikace. Ostatní certifikáty používané pro provoz HTTPS s vlastními doménami se vytvářejí a konfigurují odděleně od Identity podpisového certifikátu serveru.

Konfigurace aplikace, Azure App Service a Azure Key Vault k hostování s vlastní doménou a HTTPS:

1. Vytvořte App Service plán s úrovní plánu nebo Basic B1 vyšší. App Service používání vlastních domén vyžaduje úroveň služby nebo Basic B1 vyšší.

2. Vytvořte certifikát PFX pro zabezpečenou komunikaci prohlížeče webu (protokol HTTPS) se společným názvem plně kvalifikovaného názvu domény (FQDN) webu, který řídí vaše organizace (například www.contoso.com ). Vytvořte certifikát pomocí:

   • Použití klíče
     • Ověření digitálního podpisu ( digitalSignature )
     • Šifrování klíče ( keyEncipherment )
   • Použití rozšířeného nebo rozšířeného klíče
     • Ověřování klientů (1.3.6.1.5.5.7.3.2)
     • Ověřování serveru (1.3.6.1.5.5.7.3.1)

   K vytvoření certifikátu použijte jeden z následujících přístupů nebo jiný vhodný nástroj nebo online službu:

   • Azure Key Vault
   • MakeCert na Windows
   • Openssl

   Poznamenejte si heslo, které se později použije k importu certifikátu do Azure Key Vault.

   Další informace o certifikátech Azure Key Vault najdete v tématu Azure Key Vault: Certifikáty.

3. Vytvořte nový trezor Azure Key Vault nebo použijte existující trezor klíčů ve vašem předplatném Azure.

4. V oblasti Certifikáty trezoru klíčů naimportujte certifikát lokality PFX. Zaznamente si kryptografický otisk certifikátu, který se použije v konfiguraci aplikace později.

5. V Azure Key Vault vytvořte nový certifikát podepsaný svým držitelem pro podepisování Identity tokenů serveru. Zadejte název certifikátu a předmět certifikátu. Předmět je zadaný jako , kde zástupný symbol je běžný název CN={COMMON NAME} {COMMON NAME} certifikátu. Běžným názvem může být libovolný alfanumerický řetězec. Například je CN=IdentityServerSigning platným subjektem certifikátu. Použijte výchozí nastavení Konfigurace rozšířených zásad. Zaznamente si kryptografický otisk certifikátu, který se použije v konfiguraci aplikace později.

6. Přejděte na Azure App Service v Azure Portal a vytvořte nový App Service s následující konfigurací:

   • Publikovat nastavte na Code .
   • Zásobník modulu runtime nastavený na modul runtime aplikace.
   • V případě SKU a velikosti ověřte, že App Service je Basic B1 nebo vyšší. App Service používání vlastních domén vyžaduje úroveň služby nebo Basic B1 vyšší.

7. Jakmile Azure vytvoří App Service, otevřete konfiguraci aplikace a přidejte nové nastavení aplikace určující kryptografický otisk certifikátu zaznamenaný dříve. Klíč nastavení aplikace je WEBSITE_LOAD_CERTIFICATES . Kryptografický otisk certifikátu v hodnotě nastavení aplikace oddělte čárkou, jak ukazuje následující příklad:

   • Klíč: WEBSITE_LOAD_CERTIFICATES
   • Hodnota: 57443A552A46DB...D55E28D412B943565,29F43A772CB6AF...1D04F0C67F85FB0B1

   V Azure Portal je ukládání nastavení aplikace dvoukrokový proces: Uložte nastavení klíč-hodnota a pak vyberte tlačítko Uložit v WEBSITE_LOAD_CERTIFICATES horní části okna.

8. Vyberte nastavení TLS/SSL aplikace. Vyberte Certifikáty privátních klíčů (.pfx). Pomocí procesu Import Key Vault Certificate dvakrát importujte certifikát lokality pro komunikaci pomocí protokolu HTTPS i podpisový certifikát serveru podepsaný svým Identity držitelem.

9. Přejděte do okna Vlastní domény. Na webu doménového registrátora nakonfigurujte doménu pomocí IP adresy Custom Domain ID ověření domény. Typická konfigurace domény zahrnuje:

   • Záznam A s hostitelem a hodnotou IP adresy @ z Azure Portal.
   • Záznam TXT s hostitelem a hodnotou ID ověření vygenerované Azure a poskytnutého asuid Azure Portal.

   Nezapomeňte změny správně uložit na webu doménového registrátora. Některé weby registrátora vyžadují dvoukrokový proces ukládání záznamů domény: Jeden nebo více záznamů se uloží jednotlivě a pak se registrace domény aktualizuje samostatným tlačítkem.

10. Vraťte se do okna Vlastní domény v Azure Portal. Vyberte Přidat vlastní doménu. Vyberte možnost Záznam A. Zadejte doménu a vyberte Ověřit. Pokud jsou záznamy domény správné a šíří se po internetu, portál umožňuje vybrat tlačítko Přidat vlastní doménu.

    Může trvat několik dnů, než se změny registrace domény rozšíří mezi internetové názvové servery domény (DNS) poté, co je zpracuje doménový registrátor. Pokud se záznamy domény ne aktualizují do tří pracovních dnů, ověřte, že jsou záznamy správně nastavené u doménového registrátora, a kontaktujte zákaznickou podporu.

11. V okně Vlastní domény je stav SSL pro doménu označený Not Secure jako . Vyberte odkaz Přidat vazbu. Vyberte certifikát HTTPS lokality z trezoru klíčů pro vlastní vazbu domény.

12. V Visual Studio otevřete soubor nastavení aplikace projektu serveru ( appsettings.json nebo appsettings.Production.json ). V Identity části Konfigurace serveru přidejte následující Key část. Zadejte předmět certifikátu podepsaného svým držitelem pro Name klíč. V následujícím příkladu je běžný název certifikátu přiřazený v trezoru klíčů . Výsledkem je IdentityServerSigning předmět CN=IdentityServerSigning :

    "IdentityServer": {
    
      ...
    
      "Key": {
        "Type": "Store",
        "StoreName": "My",
        "StoreLocation": "CurrentUser",
        "Name": "CN=IdentityServerSigning"
      }
    },
    

13. V Visual Studio vytvořit profil Azure App Service pro projekt Server. V řádku nabídek vyberte: Build > Publish > New > Azure Azure App Service (Windows or Linux (Publikovat nový Azure > Windows Nebo Linux). Když Visual Studio k předplatnému Azure, můžete nastavit Zobrazení prostředků Azure podle typu prostředku. Přejděte do seznamu Webová aplikace, vyhledejte App Service aplikace a vyberte ji. Vyberte Dokončit.

14. Když Visual Studio do okna Publikovat, automaticky se detekují závislosti trezoru SQL Server a databázové služby.

    Pro službu trezoru klíčů nejsou potřeba žádné změny konfigurace výchozích nastavení.

    Pro účely testování je možné s aplikací nasadit místní databázi SQLite, která je ve výchozím nastavení nakonfigurovaná Blazor šablonou, bez další konfigurace. Konfigurace jiné databáze pro Identity Server v produkčním prostředí je nad rámec tohoto článku. Další informace najdete v databázových zdrojích v následujících sadách dokumentace:

    • App Service
    • Identity Server

15. V horní části okna vyberte odkaz Upravit pod názvem profilu nasazení. Změňte cílovou adresu URL na adresu URL vlastní domény webu (například https://www.contoso.com ). Uložte nastavení.

16. Publikujte aplikaci. Visual Studio otevře okno prohlížeče a požádá o web ve vlastní doméně.

Dokumentace k Azure obsahuje další podrobnosti o používání služeb Azure a vlastních domén s vazbou TLS v App Service, včetně informací o použití záznamů CNAME místo záznamů A. Další informace naleznete v následujících zdrojích:

• App Service dokumentace
• Kurz: Mapování existujícího vlastního názvu DNS na službu Azure App Service
• Zabezpečení vlastního názvu DNS pomocí vazby TLS/SSL v Azure App Service
• Azure Key Vault

Doporučujeme použít nové okno prohlížeče v soukromém nebo anonymním režimu pro každý test aplikace spuštěný po změně aplikace, konfigurace aplikace nebo služeb Azure v Azure Portal. Odstranění chyby z předchozího testovacího běhu může způsobit neúspěšné ověření nebo autorizaci při testování lokality, i když je konfigurace cookie lokality správná. Další informace o tom, jak Visual Studio pro každé testovací běhy otevřít nové okno prohlížeče v soukromém nebo anonymním režimu, najdete v části s a Cookie data webu.

Když App Service konfigurace v aplikaci Azure Portal, aktualizace se projeví rychle, ale nejsou okamžité. Někdy musíte chvíli počkat, než se App Service počítač restartuje, aby se změna konfigurace projeví.

Pokud chcete vyřešit problém s načítáním certifikátu, spusťte následující příkaz v Azure Portal prostředí PowerShell Kudu. Příkaz zobrazí seznam certifikátů, ke kterým má aplikace přístup z CurrentUser > My úložiště certifikátů. Výstup obsahuje předměty certifikátů a kryptografický otisk, které jsou užitečné při ladění aplikace:

Get-ChildItem -path Cert:\CurrentUser\My -Recurse | Format-List DnsNameList, Subject, Thumbprint, EnhancedKeyUsageList

Řešení potíží

Běžné chyby

• Chybné konfigurace aplikace nebo Identity zprostředkovatele (IP)

  Nejčastější chyby jsou způsobené nesprávnou konfigurací. Tady je několik příkladů:

  • V závislosti na požadavcích scénáře brání chybějící nebo nesprávná autorita, instance, ID tenanta, doména tenanta, ID klienta nebo identifikátor URI přesměrování aplikaci v ověřování klientů.
  • Nesprávný obor přístupového tokenu brání klientům v přístupu ke koncovým bodům webového rozhraní API serveru.
  • Nesprávná nebo chybějící oprávnění rozhraní API serveru brání klientům v přístupu ke koncovým bodům webového rozhraní API serveru.
  • Spuštění aplikace na jiném portu, než je nakonfigurované v identifikátoru URI přesměrování Identity registrace aplikace poskytovatele.

  V částech s pokyny pro konfiguraci najdete příklady správné konfigurace. Pečlivě zkontrolujte každou část článku a zkontrolujte chybné konfigurace aplikace a IP adresy.

  Pokud se konfigurace zdá být správná:

  • Analýza aplikačních protokolů

  • Prozkoumejte síťový provoz mezi klientskou aplikací a IP adresou nebo serverovou aplikací pomocí vývojářských nástrojů prohlížeče. Ip adresa nebo serverová aplikace často vrátí klientovi přesnou chybovou zprávu nebo zprávu s vodítkem k příčině problému. Vývojářské nástroje najdete v následujících článcích:

    • Google Chrome (dokumentace Google)
    • Microsoft Edge
    • Mozilla Firefox (dokumentace Mozilla)

  • Dekódujte obsah souboru JWT (JSON Web Token), který se používá k ověřování klienta nebo přístupu k webovému rozhraní API serveru v závislosti na tom, kde k problému dochází. Další informace najdete v tématu Kontrola obsahu souboru JSON WEB TOKEN (JWT).

  Dokumentační tým reaguje na zpětnou vazbu k dokumentům a chyby v článcích (otevřete problém v části Tato zpětná vazba na stránce), ale nemůže poskytovat podporu k produktům. Při řešení potíží s aplikací je k dispozici několik veřejných fór podpory. Doporučujeme postupovat následovně:

  • Stack Overflow (značka: blazor )
  • ASP.NET Core Slack Team
  • Blazor Gitter

  Předchozí fóra nejsou vlastněna ani řízena společností Microsoft.

  V případě zpráv o chybách architektury bez zabezpečení, bez citlivosti a bez důvěrných reprodukovatelných architektur otevřete problém v ASP.NET Core produktové jednotce. Neotevřete problém s produktovou jednotkou, dokud pečlivě neprošetříte příčinu problému a nemůžete ho vyřešit sami a s pomocí komunity na veřejném fóru podpory. Produktová jednotka nemůže řešit potíže s jednotlivými aplikacemi, které jsou poškozené kvůli jednoduché chybné konfiguraci nebo případům použití zahrnujícím služby třetích stran. Pokud je sestava citlivá nebo důvěrná nebo popisuje potenciální chybu zabezpečení v produktu, kterou mohou útočníci zneužít, podívejte se na téma Hlášení problémů a chyb zabezpečení (dotnet/aspnetcore GitHub úložiště).

• Neautorizovaný klient pro AAD

  info: Microsoft.AspNetCore.Authorization.DefaultAuthorizationService[2] Autorizace se nezdařila. Tyto požadavky nebyly splněny: DenyAnonymousAuthorizationRequirement: Vyžaduje ověřeného uživatele.

  Chyba zpětného volání přihlášení z AAD:

  • Chyba: unauthorized_client
  • Popis: AADB2C90058: The provided application is not configured to allow public clients.

  Řešení chyby:

  1. V Azure Portal přístup k manifestu aplikace.
  2. Nastavte allowPublicClient atribut na null nebo true .

Cookies a data lokality

CookieData webů a se mohou uchovat napříč aktualizacemi aplikací a interferovat s testováním a řešením potíží. Při provádění změn kódu aplikace, změn uživatelského účtu u poskytovatele nebo změn konfigurace aplikace zprostředkovatele vymažte následující:

• Přihlášení cookie uživatele
• Aplikace cookie
• Uložená data lokality a uložená v mezipaměti

Jedním z přístupů, jak zabránit tomu, aby se při testování a řešení potíží přerušují cookie data lokality, je:

• Konfigurace prohlížeče
  • Pro testování použijte prohlížeč, který můžete nakonfigurovat tak, aby při každém zavření prohlížeče odstranil všechna data a cookie data webu.
  • Ujistěte se, že je prohlížeč ručně zavřen nebo integrované vývojové prostředí (IDE) kvůli jakékoli změně konfigurace aplikace, testovacího uživatele nebo zprostředkovatele.
• Pomocí vlastního příkazu otevřete prohlížeč v anonymním nebo privátním režimu v Visual Studio:
  • V dialogovém okně Procházet Visual Studio tlačítko Spustit.
  • Vyberte tlačítko Přidat.
  • Do pole Program zadejte cestu k prohlížeči. Následující spustitelné cesty jsou typická umístění instalace pro Windows 10. Pokud je váš prohlížeč nainstalovaný na jiném místě nebo pokud ho Windows 10, zadejte cestu ke spustitelnému souboru prohlížeče.
    • Microsoft Edge:C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
    • Google Chrome: C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
    • Mozilla Firefox: C:\Program Files\Mozilla Firefox\firefox.exe
  • Do pole Argumenty zadejte možnost příkazového řádku, kterou prohlížeč používá k otevření v anonymním nebo privátním režimu. Některé prohlížeče vyžadují adresu URL aplikace.
    • Microsoft Edge: Použijte -inprivate .
    • Google Chrome: Použijte --incognito --new-window {URL} , kde zástupný symbol je adresa URL, která se má otevřít {URL} (například https://localhost:5001 ).
    • Mozilla Firefox: Použijte -private -url {URL} , kde zástupný symbol je adresa URL, která se má otevřít {URL} (například https://localhost:5001 ).
  • Do pole Popisný název zadejte název. Například, Firefox Auth Testing.
  • Vyberte tlačítko OK.
  • Pokud se chcete vyhnout výběru profilu prohlížeče pro každou iteraci testování pomocí aplikace, nastavte profil jako výchozí pomocí tlačítka Nastavit jako výchozí.
  • Ujistěte se, že integrované vývojové prostředí zavře prohlížeč kvůli jakékoli změně konfigurace aplikace, testovacího uživatele nebo zprostředkovatele.

Upgrady aplikací

Funkční aplikace může selhat okamžitě po upgradu .NET Core SDK na vývojovém počítači nebo změně verzí balíčků v rámci aplikace. V některých případech může při provádění významných upgradů dojít k přerušení aplikace v neschválených balíčcích. Většinu těchto problémů můžete vyřešit pomocí těchto pokynů:

1. Vymažte mezipaměť balíčků NuGet systému spuštěním příkazu dotnet nuget locals all --clear z příkazového prostředí.
2. Odstraňte složky a bin obj projektu.
3. Obnovte a znovu sestavte projekt.
4. Před znovunasazování aplikace odstraňte všechny soubory ve složce nasazení na serveru.

Spuštění aplikace Server

Při testování hostovaného řešení a řešení souvisejících potíží se ujistěte, že aplikaci používáte Blazor z Server projektu. Například v Visual Studio před zahájením aplikace potvrďte, že je projekt Server zvýrazněný v Průzkumník řešení, a to pomocí libovolného z následujících přístupů:

• Vyberte tlačítko Run (Spustit).
• V nabídce > použijte Ladění spustit ladění.
• Stiskněte klávesu F5.

Kontrola obsahu souboru JSON Web Token (JWT)

Pokud chcete dekódovat JSON Web Token (JWT), použijte nástroj jwt.ms Microsoftu. Hodnoty v uživatelském rozhraní nikdy neopustí váš prohlížeč.

Příklad kódovaného JWT (zkráceně pro zobrazení):

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIsImtpZCI6Ilg1ZVhrNHh5b2pORnVtMWtsMll0djhkbE5QNC1j... bQdHBHGcQQRbW7Wmo6SWYG4V_bU55Ug_PW4pLPr20tTS8Ct7_uwy9DWrzCMzpD-EiwT5IjXwlGX3IXVjHIlX50IVIydBoPQtadvT7saKo1G5Jmutgq41o-dmz6-yBMKV2_nXA25Q

Příklad JWT dekódovaný nástrojem pro aplikaci, která se ověřuje vůči Azure AAD B2C:

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "X5eXk4xyojNFum1kl2Ytv8dlNP4-c57dO6QGTVBwaNk"
}.{
  "exp": 1610059429,
  "nbf": 1610055829,
  "ver": "1.0",
  "iss": "https://mysiteb2c.b2clogin.com/5cc15ea8-a296-4aa3-97e4-226dcc9ad298/v2.0/",
  "sub": "5ee963fb-24d6-4d72-a1b6-889c6e2c7438",
  "aud": "70bde375-fce3-4b82-984a-b247d823a03f",
  "nonce": "b2641f54-8dc4-42ca-97ea-7f12ff4af871",
  "iat": 1610055829,
  "auth_time": 1610055822,
  "idp": "idp.com",
  "tfp": "B2C_1_signupsignin"
}.[Signature]

Další zdroje informací

• Nasazení do Azure App Service
• Import certifikátu z Key Vault (dokumentace Azure)
• Blazor WebAssemblyASP.NET Core další scénáře zabezpečení
• Neověřené nebo neoprávněné požadavky webového rozhraní API v aplikaci se zabezpečeným výchozím klientem
• Konfigurace ASP.NET Core pro práci s proxy servery a nástroji pro vyrovnávání zatížení: Obsahuje pokyny pro:
  • Použití middlewaru forwarded headers k zachování informací schématu HTTPS mezi proxy servery a interními sítěmi.
  • Další scénáře a případy použití, včetně ruční konfigurace schématu, změn cesty požadavku pro správné směrování požadavků a předávání schématu požadavků pro linuxové a jiné reverzní servery než IIS.