Konfigurace ověřování Windows v ASP.NET Core

Autoři: Rick Anderson a Kirk Larkin

Ověřování systému Windows (označované také jako Ověřování Negotiate, Kerberos nebo NTLM) je možné nakonfigurovat pro aplikace ASP.NET Core hostované ve službě IISKestrel nebo HTTP.sys.

Ověřování systému Windows využívá operační systém k ověřování uživatelů aplikací ASP.NET Core. Ověřování systému Windows se používá pro servery, které běží v podnikové síti pomocí identit domény služby Active Directory nebo účtů systému Windows k identifikaci uživatelů. Ověřování systému Windows je nejvhodnější pro intranetová prostředí, ve kterých uživatelé, klientské aplikace a webové servery patří do stejné domény Windows.

Kdy použít ověřování systému Windows

Ověřování systému Windows je vhodné pro webové aplikace, které pracují v privátní interní síti organizace, přístupné jenom zaměstnancům (a dalším autorizovaným uživatelům) ve stejné síti. Správa uživatelů se provádí ve službě Active Directory (AD) a uživatelé k ověření používají svůj stávající účet domény Systému Windows.

Ověřování systému Windows poskytuje pro intranetové aplikace několik výhod:

• Bezproblémové uživatelské prostředí – Uživatelé se automaticky ověřují na základě aktivní relace Windows nebo se zobrazí výzva k zadání přihlašovacích údajů systému Windows pomocí standardního dialogového okna prohlížeče.
• Integrace se službou Active Directory – využívá stávající zásady zabezpečení a infrastruktury Windows, včetně skupin uživatelů, uzamčení účtů a vícefaktorového ověřování (MFA).
• Zabezpečené zpracování přihlašovacích údajů – Ověřování se zpracovává prostřednictvím zabezpečených protokolů, jako je Kerberos, bez nutnosti spravovat samostatné přihlašovací údaje uživatele.
• Autorizace na základě role – Aplikace mají přístup k informacím o uživatelích a skupinách ze služby Active Directory a umožňují řízení přístupu na základě role (RBAC) v rámci aplikace.
• Nižší režijní náklady na správu – Není nutné udržovat samostatnou uživatelskou databázi nebo systém pro správu přihlašovacích údajů.

Díky tomu je ověřování systému Windows ideální pro organizace, které chtějí využívat stávající infrastrukturu Windows, jako jsou intranetové portály.

Note

Ověřování systému Windows není podporováno u protokolu HTTP/2. I když můžou být problémy s ověřováním odeslány prostřednictvím odpovědí HTTP/2, musí klient přejít na http/1.1, aby proces ověřování dokončil. Jedná se o omezení protokolu, nikoli o vyřazení ověřování systému Windows. Po ověření může normální komunikace HTTP/2 pokračovat pro následné požadavky.

U veřejných aplikací se nedoporučuje ověřování systému Windows kvůli obavám o zabezpečení a použitelnost. Mezi tyto důvody patří:

• Ověřování systému Windows je nejlépe udržovat interně, aby chránilo službu Active Directory; vystavení této služby mimo interní síť představuje bezpečnostní riziko.
• Externí uživatelé nemají účty domény Windows.
• Konfigurace nezbytné síťové infrastruktury je složitá a brány firewall nebo proxy servery můžou zasahovat do procesu ověřování.
• Není to multiplatformní a neposkytuje možnosti přizpůsobení pro návrhy a uživatelská prostředí.

Alternativy pro různé scénáře

V závislosti na požadavcích vaší aplikace zvažte tyto alternativy:

Pro veřejné aplikace:

• OpenID Connect s externími zprostředkovateli identity
• ASP.NET Core Identity s místními uživatelskými účty (úvod do Identity ASP.NET Core)
• Azure Active Directory (AAD) pro prostředí Microsoftu 365

Pro smíšená prostředí s intranetem i externími uživateli:

• Active Directory Federation Services (ADFS) s OpenID Connect
• Azure Active Directory s hybridní konfigurací

Pro podniková prostředí pomocí moderního ověřování:

• Azure Active Directory s jednotným přihlašováním
• Řešení založená na SAML se zprostředkovateli identit třetích stran

Scénáře proxy serveru a nástroje pro vyrovnávání zatížení

Ověřování systému Windows je stavový scénář, který se primárně používá v intranetu, kde proxy server nebo nástroj pro vyrovnávání zatížení obvykle nezpracuje provoz mezi klienty a servery. Pokud se používá proxy server nebo nástroj pro vyrovnávání zatížení, ověřování systému Windows funguje jenom v případě, že proxy server nebo nástroj pro vyrovnávání zatížení:

• Zpracovává ověřování.
• Předá ověřovací informace uživatele aplikaci (například v hlavičce požadavku), která funguje na ověřovacích informacích.

Alternativou k ověřování systému Windows v prostředích, kde se používají proxy servery a nástroje pro vyrovnávání zatížení, je služba Active Directory Federated Services (ADFS) s OpenID Connect (OIDC).

IIS/IIS Express

Microsoft.AspNetCore.Authentication.Negotiate Přidejte balíček NuGet a ověřovací služby voláním AddAuthenticationProgram.cs:

using Microsoft.AspNetCore.Authentication.Negotiate;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
   .AddNegotiate();

builder.Services.AddAuthorization(options =>
{
    options.FallbackPolicy = options.DefaultPolicy;
});
builder.Services.AddRazorPages();

var app = builder.Build();
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

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

app.MapRazorPages();

app.Run();

Předchozí kód vygeneroval šablona ASP.NET Core Razor Pages se zadaným ověřováním systému Windows.

Nastavení spuštění (ladicí program)

Konfigurace nastavení spuštění má vliv jenom na Properties/launchSettings.json soubor služby IIS Express a nenakonfiguruje službu IIS pro ověřování systému Windows. Konfigurace serveru je vysvětlená v části IIS .

Šablony webových aplikací dostupné prostřednictvím sady Visual Studio nebo rozhraní příkazového řádku .NET je možné nakonfigurovat tak, aby podporovaly ověřování systému Windows, které soubor aktualizuje Properties/launchSettings.json automaticky.

Visual Studio

Nový projekt

Vytvořte novou Razor aplikaci Pages nebo MVC. V dialogovém okně Další informace nastavte typ ověřování na Windows.

Spustit aplikaci. Uživatelské jméno se zobrazí v uživatelském rozhraní vykreslené aplikace.

Existující projekt

Vlastnosti projektu umožňují ověřování systému Windows a zakazují anonymní ověřování. Otevření dialogového okna spouštěcích profilů:

1. V Průzkumníku řešení klikněte pravým tlačítkem na projekt a vyberte Vlastnosti.
2. Vyberte kartu Ladění > Obecné a vyberte Otevřít uživatelské rozhraní pro ladění profilů spouštění.
3. Zrušte zaškrtnutí políčka Povolit anonymní ověřování.
4. Zaškrtněte políčko Povolit ověřování systému Windows.

Alternativně lze vlastnosti nakonfigurovat v iisSettings uzlu launchSettings.json souboru:

"iisSettings": {
    "windowsAuthentication": true,
    "anonymousAuthentication": false,
    "iisExpress": {
        "applicationUrl": "http://localhost:52171/",
        "sslPort": 44308
    }
}

.NET CLI

Nový projekt

Proveďte příkaz dotnet new s argumentem webapp a přepínačem --auth Windows (ASP.NET Core Web App):

dotnet new webapp --auth Windows

Existující projekt

iisSettings Aktualizujte uzel launchSettings.json souboru:

"iisSettings": {
    "windowsAuthentication": true,
    "anonymousAuthentication": false,
    "iisExpress": {
        "applicationUrl": "http://localhost:52171/",
        "sslPort": 44308
    }
}

služba IIS

Služba IIS používá modul ASP.NET Core k hostování aplikací ASP.NET Core. Ověřování systému Windows je nakonfigurováno pro službu IIS prostřednictvím souboru web.config . Následující části ukazují, jak:

• Zadejte místní soubor web.config , který při nasazení aplikace aktivuje ověřování systému Windows na serveru.
• Pomocí Správce služby IIS nakonfigurujte soubor web.config aplikace ASP.NET Core, která již byla nasazena na server.

Pokud jste to ještě neudělali, povolte službě IIS hostování aplikací ASP.NET Core. Další informace naleznete v tématu Hostitel ASP.NET Core ve Windows se službou IIS.

Povolte službu role IIS pro ověřování systému Windows. Další informace naleznete v tématu Povolení ověřování systému Windows ve službě role IIS (viz krok 2).

Middleware integrace služby IIS je nakonfigurovaný tak, aby automaticky ověřoval požadavky ve výchozím nastavení. Další informace naleznete v tématu Hostitel ASP.NET Core ve Windows se službou IIS: Možnosti služby IIS (AutomaticAuthentication).

Modul ASP.NET Core je ve výchozím nastavení nakonfigurovaný tak, aby předával ověřovací token Windows do aplikace. Další informace najdete v tématu ASP.NET Referenční informace o konfiguraci základního modulu: Atributy elementu aspNetCore.

Použijte některý z následujících přístupů:

• Před publikováním a nasazením projektu přidejte do kořenového adresáře projektu následující soubor web.config :

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <location path="." inheritInChildApplications="false">
      <system.webServer>
        <security>
          <authentication>
            <anonymousAuthentication enabled="false" />
            <windowsAuthentication enabled="true" />
          </authentication>
        </security>
      </system.webServer>
    </location>
  </configuration>
  

  Pokud projekt publikuje sada .NET SDK (bez vlastnosti nastavené na v souboru projektu), publikovaný soubor <IsTransformWebConfigDisabled> obsahuje true oddíl. Další informace o <IsTransformWebConfigDisabled> vlastnosti naleznete v web.config souboru.

• Po publikování a nasazení projektu proveďte konfiguraci na straně serveru pomocí Správce služby IIS:

  1. Ve Správci služby IIS vyberte web služby IIS v uzlu Lokality na bočním panelu Připojení .
  2. Poklikejte na Ověřování v oblasti SLUŽBY IIS .
  3. Vyberte anonymní ověřování. Na bočním panelu Akcí vyberte Zakázat.
  4. Vyberte Ověřování systému Windows. Na bočním panelu Akcí vyberte Povolit.

  Po provedení těchto akcí správce služby IIS upraví soubor web.config aplikace. Uzel <system.webServer><security><authentication> se přidá s aktualizovanými nastaveními aanonymousAuthenticationwindowsAuthentication:

  <system.webServer>
    <security>
      <authentication>
        <anonymousAuthentication enabled="false" />
        <windowsAuthentication enabled="true" />
      </authentication>
    </security>
  </system.webServer>
  

  Oddíl <system.webServer> přidaný do souboruweb.config správcem služby IIS je mimo oddíl aplikace <location> přidaný sadou .NET SDK při publikování aplikace. Vzhledem k tomu, že se oddíl přidá mimo <location> uzel, zdědí nastavení všechny dílčí aplikace do aktuální aplikace. Pokud chcete zabránit dědičnosti, přesuňte přidaný <security> oddíl uvnitř oddílu <location><system.webServer> , který poskytuje sada .NET SDK.

  Když správce služby IIS přidá konfiguraci služby IIS, ovlivní to jenom soubor web.config aplikace na serveru. Následné nasazení aplikace může přepsat nastavení na serveru, pokud je kopie souboru web.config serveru nahrazena souborem web.config projektu. Ke správě nastavení použijte některý z následujících přístupů:

  • Pomocí Správce služby IIS obnovte nastavení v souboru web.config po přepsání souboru při nasazení.
  • Přidejte do aplikace soubor web.config místně s nastavením.

Kestrel

BalíčekMicrosoft.AspNetCore.Authentication.Negotiate NuGet lze použít Kestrel k povolení Windows ověřování pomocí Negotiate a Kerberos na Windows, Linuxu a macOS.

Warning

Přihlašovací údaje je možné uchovávat napříč požadavky na připojení. Pokud proxy server neudržuje spřažení připojení 1:1 (trvalé připojení) s Kestrelproxy serverem, nesmí být použito ověřování vyjednat.

Note

Obslužná rutina Negotiate zjistí, jestli podkladový server nativně podporuje ověřování systému Windows a jestli je povolený. Pokud server podporuje ověřování systému Windows, ale je zakázané, zobrazí se chyba s výzvou k povolení implementace serveru. Pokud je na serveru povolené ověřování systému Windows, obslužná rutina Negotiate transparentně předává žádosti o ověření.

Ověřování a záložní zásady autorizace jsou povoleny následujícím zvýrazněným kódem v Program.cs:

using Microsoft.AspNetCore.Authentication.Negotiate;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
   .AddNegotiate();

builder.Services.AddAuthorization(options =>
{
    options.FallbackPolicy = options.DefaultPolicy;
});
builder.Services.AddRazorPages();

var app = builder.Build();
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

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

app.MapRazorPages();

app.Run();

Předchozí kód vygeneroval šablona ASP.NET Core Razor Pages se zadaným ověřováním systému Windows.

Zvýrazněné čáry:

• 5–6: Zaregistrujte a nakonfigurujte AddAuthentication a AddNegotiate obslužnou rutinu ověřování Negotiate.
• 8–11: AddAuthorization Záložní politika ve výchozím nastavení vynucuje přihlášené uživatele.
• 26: UseAuthentication Spustí obslužné rutiny ověřování pro každý požadavek a naplní HttpContext.User.
• 27: UseAuthorization vyhodnocuje zásady autorizace, včetně záložních zásad.

Note

Volání AddAuthentication a AddNegotiate registruje a konfiguruje obslužnou rutinu Negotiate; nespouští ověřování pro jednotlivé požadavky. Middleware UseAuthentication ověřování vyvolá obslužnou rutinu a naplní HttpContext.User, a musí se zobrazit před UseAuthorization pro vyhodnocení zásad.

Ověřování kerberos a řízení přístupu na základě role (RBAC)

Ověřování protokolem Kerberos v Linuxu nebo macOS neposkytuje ověřenému uživateli žádné informace o rolích. Chcete-li přidat informace o rolích a skupinách pro uživatele protokolu Kerberos, musí být obslužná rutina ověřování nakonfigurovaná tak, aby načítala role z domény LDAP. Nejzásadnější konfigurace určuje pouze doménu LDAP, na které se má dotazovat, a používá kontext ověřeného uživatele k dotazování domény LDAP:

using Microsoft.AspNetCore.Authentication.Negotiate;
using System.Runtime.InteropServices;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
    .AddNegotiate(options =>
    {
        if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
        {
            options.EnableLdap("contoso.com");
        }
    });

Některé konfigurace můžou vyžadovat pro dotazování domény LDAP konkrétní přihlašovací údaje. Přihlašovací údaje je možné zadat v následujících zvýrazněných možnostech:

using Microsoft.AspNetCore.Authentication.Negotiate;
using System.Runtime.InteropServices;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
        .AddNegotiate(options =>
        {
            if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
            {
                options.EnableLdap(settings =>
                {
                    settings.Domain = "contoso.com";
                    settings.MachineAccountName = "machineName";
                    settings.MachineAccountPassword =
                                      builder.Configuration["Password"];
                });
            }
        });

builder.Services.AddRazorPages();

Ve výchozím nastavení obslužná rutina ověřování vyjednává vnořené domény. Ve velkém nebo složitém prostředí LDAP může překlad vnořených domén způsobit pomalé vyhledávání nebo hodně paměti používané pro každého uživatele. Vnořené rozlišení domény je možné zakázat pomocí IgnoreNestedGroups této možnosti.

Anonymní žádosti jsou povolené. Pomocí ASP.NET základní autorizace můžete vyhovět anonymním požadavkům na ověření.

Konfigurace prostředí Windows

RozhraníMicrosoft.AspNetCore.Authentication.Negotiate API provádí ověřování v uživatelském režimu. Hlavní názvy služby (SPN) musí být přidány do uživatelského účtu, na kterém je spuštěna služba, nikoli do účtu počítače. Spusťte setspn -S HTTP/myservername.mydomain.com myuser v příkazovém prostředí pro správu.

Kerberos vs. NTLM

Balíček Negotiate pro Kestrel ASP.NET Core se pokusí použít Protokol Kerberos, což je bezpečnější a peformantnější schéma ověřování než NTLM:

using Microsoft.AspNetCore.Authentication.Negotiate;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
   .AddNegotiate();

builder.Services.AddAuthorization(options =>
{
    options.FallbackPolicy = options.DefaultPolicy;
});
builder.Services.AddRazorPages();

var app = builder.Build();

NegotiateDefaults.AuthenticationScheme určuje Kerberos, protože je to výchozí.

SLUŽBA IIS, IISExpress a Kestrel podporuje protokol Kerberos i NTLM.

Zkoumání www-authenticate: hlavička pomocí iis nebo IISExpress pomocí nástroje, jako je Fiddler, zobrazuje buď Negotiate nebo NTLM.

Kestrel Zobrazuje se jenom WWW-Authenticate: Negotiate

Hlavička WWW-Authenticate: Negotiate znamená, že server může používat protokol NTLM nebo Kerberos. Kestrelvyžaduje předponu Negotiate hlavičky, nepodporuje přímé zadávání NTLM v hlavičce požadavku nebo odpovědi. Protokol NTLM je podporován v Kestrelsystému , ale musí být odeslán jako Negotiate.

Pokud Kestrelchcete zjistit, jestli se používá protokol NTLM nebo Kerberos, dekóduje base64 hlavičku a zobrazí buď NTLM nebo HTTP. HTTP označuje, že se použil protokol Kerberos.

Konfigurace prostředí Linuxu a macOS

Pokyny pro připojení počítače s Linuxem nebo macOS k doméně Windows jsou k dispozici v článku Připojení Azure Data Studia k SQL Serveru pomocí ověřování Systému Windows – článek Kerberos . Pokyny vytvoří účet počítače pro počítač s Linuxem v doméně. Hlavní názvy služby (SPN) musí být přidány do účtu počítače.

Note

Při sledování pokynů v nástroji Connect Azure Data Studio k SQL Serveru pomocí ověřování systému Windows – článek Kerberos nahraďte python-software-properties v python3-software-properties případě potřeby.

Po připojení počítače s Linuxem nebo macOS k doméně jsou potřeba další kroky k poskytnutí souboru keytab s hlavními názvy služeb:

• Na řadiči domény přidejte do účtu počítače nové hlavní názvy služeb webové služby:
  • setspn -S HTTP/mywebservice.mydomain.com mymachine
  • setspn -S HTTP/mywebservice@MYDOMAIN.COM mymachine
• K vygenerování souboru keytab použijte ktpass :
  • ktpass -princ HTTP/mywebservice.mydomain.com@MYDOMAIN.COM -pass myKeyTabFilePassword -mapuser MYDOMAIN\mymachine$ -pType KRB5_NT_PRINCIPAL -out c:\temp\mymachine.HTTP.keytab -crypto AES256-SHA1
  • Některá pole musí být zadána velkými písmeny, jak je uvedeno.
• Zkopírujte soubor keytab na počítač s Linuxem nebo macOS.
• Vyberte soubor keytab prostřednictvím proměnné prostředí: export KRB5_KTNAME=/tmp/mymachine.HTTP.keytab
• Vyvolání pro klist zobrazení hlavních názvů služeb, které jsou aktuálně k dispozici pro použití.

Note

Soubor keytab obsahuje přihlašovací údaje pro přístup k doméně a musí být odpovídajícím způsobem chráněn.

HTTP.sys

HTTP.sys podporuje ověřování systému Windows v režimu jádra pomocí negotiate, NTLM nebo základního ověřování.

Následující kód přidá ověřování a nakonfiguruje webového hostitele aplikace tak, aby používal HTTP.sys s ověřováním systému Windows:

using Microsoft.AspNetCore.Server.HttpSys;
using System.Runtime.InteropServices;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(HttpSysDefaults.AuthenticationScheme);

if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
{
    builder.WebHost.UseHttpSys(options =>
        {
            options.Authentication.Schemes =
                AuthenticationSchemes.NTLM |
                AuthenticationSchemes.Negotiate;
            options.Authentication.AllowAnonymous = false;
        });
}

Note

HTTP.sys deleguje ověřování v režimu jádra pomocí ověřovacího protokolu Kerberos. Ověřování v uživatelském režimu není podporováno protokolem Kerberos a HTTP.sys. Účet počítače se musí použít k dešifrování tokenu protokolu Kerberos nebo lístku získaného ze služby Active Directory a předání klienta na server k ověření uživatele. Zaregistrujte hlavní název služby (SPN) pro hostitele, ne uživatele aplikace.

Note

HTTP.sys se nepodporuje na Nano Serveru verze 1709 nebo novějším. Pokud chcete používat ověřování systému Windows a HTTP.sys s Nano Serverem, použijte kontejner Jádra serveru (microsoft/windowsservercore) (viz https://hub.docker.com/_/microsoft-windows-servercore). Další informace o jádru serveru naleznete v tématu Co je možnost instalace jádra serveru v systému Windows Server?.

Autorizace uživatelů

Stav konfigurace anonymního přístupu určuje způsob, jakým [Authorize] se v aplikaci používají atributy.[AllowAnonymous] Následující dvě části vysvětlují, jak zpracovat zakázané a povolené stavy konfigurace anonymního přístupu.

Zakázat anonymní přístup

Pokud je povolené ověřování systému Windows a je zakázaný anonymní přístup, nebudou [Authorize] mít atributy [AllowAnonymous] žádný vliv. Pokud je web služby IIS nakonfigurovaný tak, aby nepovoloval anonymní přístup, požadavek nikdy nedosáhne aplikace. Z tohoto důvodu [AllowAnonymous] není atribut použitelný.

Povolit anonymní přístup

Pokud je povolené ověřování systému Windows i anonymní přístup, použijte tyto [Authorize] atributy.[AllowAnonymous] Tento [Authorize] atribut umožňuje zabezpečit koncové body aplikace, které vyžadují ověření. Atribut [AllowAnonymous] přepíše [Authorize] atribut v aplikacích, které umožňují anonymní přístup. Podrobnosti o využití atributů najdete v tématu Jednoduchá autorizace v ASP.NET Core.

Note

Ve výchozím nastavení se uživatelům, kteří nemají autorizaci pro přístup ke stránce, zobrazí prázdná odpověď HTTP 403. Middleware StatusCodePages je možné nakonfigurovat tak, aby uživatelům poskytoval lepší možnosti odepření přístupu.

Impersonation

ASP.NET Core neimplementuje zosobnění. Aplikace běží s vlastní identitou pro všechny požadavky, využívajíc fond aplikací nebo identitu procesu. Pokud by aplikace měla provést akci jménem uživatele, použijte WindowsIdentity.RunImpersonated nebo RunImpersonatedAsync v terminální vložený middleware v Program.cs. Spusťte v tomto kontextu jednu akci a pak kontext zavřete.

app.Run(async (context) =>
{
    try
    {
        var user = (WindowsIdentity)context.User.Identity!;

        await context.Response
            .WriteAsync($"User: {user.Name}\tState: {user.ImpersonationLevel}\n");

        await WindowsIdentity.RunImpersonatedAsync(user.AccessToken, async () =>
        {
            var impersonatedUser = WindowsIdentity.GetCurrent();
            var message =
                $"User: {impersonatedUser.Name}\t" +
                $"State: {impersonatedUser.ImpersonationLevel}";

            var bytes = Encoding.UTF8.GetBytes(message);
            await context.Response.Body.WriteAsync(bytes, 0, bytes.Length);
        });
    }
    catch (Exception e)
    {
        await context.Response.WriteAsync(e.ToString());
    }
});

Microsoft.AspNetCore.Authentication.Negotiate I když balíček umožňuje ověřování ve Windows, Linuxu a macOS, zosobnění se podporuje jenom ve Windows.

Transformace prohlášení

Při hostování se službou IIS AuthenticateAsync se nevolá interně za účelem inicializace uživatele. Proto se implementace použitá IClaimsTransformation k transformaci deklarací identity po každém ověření ve výchozím nastavení neaktivuje. Další informace a příklad kódu, který aktivuje transformace deklarací identity, najdete v tématu Rozdíly mezi procesem a hostování mimo proces.

Dodatečné zdroje

• dotnet publish
• Hostování ASP.NET Core ve Windows pomocí služby IIS
• Modul ASP.NET Core (ANCM) pro službu IIS
• Profily publikování sady Visual Studio (.pubxml) pro nasazení aplikace ASP.NET Core