ASP.NET Core에서 Windows 인증 구성

작성자: Rick Anderson 및 Kirk Larkin

Windows 인증(협상, Kerberos 또는 NTLM 인증이라고도 함)은 IIS, Kestrel 또는 HTTP.sys를 사용하여 호스트된 ASP.NET Core 앱에 대해 구성될 수 있습니다.

Windows 인증은 운영 체제를 사용하여 ASP.NET Core 앱의 사용자를 인증합니다. Windows 인증은 Active Directory 도메인 ID 또는 Windows 계정을 사용하여 사용자를 식별하는 회사 네트워크에서 실행되는 서버에 사용됩니다. Windows 인증은 사용자, 클라이언트 앱 및 웹 서버가 동일한 Windows 도메인에 속하는 인트라넷 환경에 가장 적합합니다.

Windows 인증을 사용하는 경우

Windows 인증은 조직의 개인 내부 네트워크 내에서 작동하는 웹 애플리케이션에 적합하며, 동일한 네트워크 내의 직원(및 기타 권한 있는 사용자)만 액세스할 수 있습니다. 사용자 관리는 AD(Active Directory) 내에서 수행되며 사용자는 기존 Windows 도메인 계정을 사용하여 인증합니다.

Windows 인증은 인트라넷 애플리케이션에 다음과 같은 몇 가지 이점을 제공합니다.

• 원활한 사용자 환경 - 사용자는 활성 Windows 세션에 따라 자동으로 인증되거나 표준 브라우저 대화 상자를 통해 Windows 자격 증명을 입력하라는 메시지가 표시됩니다.
• Active Directory와의 통합 - 사용자 그룹, 계정 잠금 및 MFA(다단계 인증)를 비롯한 기존 Windows 인프라 및 보안 정책을 활용합니다.
• 보안 자격 증명 처리 - 인증은 별도의 사용자 자격 증명을 관리할 필요 없이 Kerberos와 같은 보안 프로토콜을 통해 처리됩니다.
• 역할 기반 권한 부여 - 애플리케이션은 Active Directory에서 사용자 및 그룹 정보에 액세스하여 애플리케이션 내에서 RBAC(역할 기반 액세스 제어)를 사용하도록 설정할 수 있습니다.
• 관리 오버헤드 감소 - 별도의 사용자 데이터베이스 또는 자격 증명 관리 시스템을 유지 관리할 필요가 없습니다.

따라서 Windows 인증은 인트라넷 포털과 같은 기존 Windows 인프라를 사용하려는 조직에 적합합니다.

Note

Windows 인증은 HTTP/2로 지원되지 않습니다. HTTP/2 응답을 통해 인증 챌린지를 보낼 수 있지만 인증 프로세스를 완료하려면 클라이언트가 HTTP/1.1로 다운그레이드해야 합니다. 이는 Windows 인증 사용 중단이 아니라 프로토콜 제한 사항입니다. 인증되면 후속 요청에 대해 일반 HTTP/2 통신을 다시 시작할 수 있습니다.

공용 애플리케이션의 경우 보안 및 유용성 문제로 인해 Windows 인증을 권장하지 않습니다. 이러한 이유는 다음과 같습니다.

• Windows 인증은 Active Directory를 보호하기 위해 내부로 유지하는 것이 가장 좋습니다. 내부 네트워크 외부에 노출하면 보안 위험이 발생합니다.
• 외부 사용자에게는 Windows 도메인 계정이 없습니다.
• 필요한 네트워크 인프라를 안전하게 구성하는 것은 복잡하며 방화벽 또는 프록시가 인증 프로세스를 방해할 수 있습니다.
• 플랫폼 간이 아니며 디자인 및 사용자 환경에 대한 사용자 지정 옵션을 제공하지 않습니다.

다양한 시나리오에 대한 대안

애플리케이션 요구 사항에 따라 다음 대안을 고려합니다.

공용 애플리케이션의 경우:

• 외부 ID 공급자를 사용하여 OpenID Connect
• 로컬 사용자 계정이 있는 ASP.NET CoreIdentity(ASP.NET Core 소개Identity)
• Microsoft 365 환경용 AAD(Azure Active Directory)

인트라넷 및 외부 사용자가 모두 있는 혼합 환경의 경우:

• OpenID Connect를 사용하는 ADFS(Active Directory Federation Services)
• 하이브리드 구성을 사용하는 Azure Active Directory

최신 인증을 사용하는 회사 환경의 경우:

• Single Sign-On을 사용하는 Azure Active Directory
• 타사 ID 공급자를 사용하는 SAML 기반 솔루션

프록시 및 부하 분산 장치 시나리오

Windows 인증은 프록시 또는 부하 분산 장치가 클라이언트와 서버 간의 트래픽을 처리하지 않는 인트라넷에서 주로 사용되는 상태 저장 시나리오입니다. 프록시 또는 부하 분산 장치를 사용하는 경우 Windows 인증은 프록시 또는 부하 분산 장치가 다음을 수행하는 경우에만 작동합니다.

• 인증을 처리합니다.
• 사용자 인증 정보를 인증 정보에 작용하는 앱(예: 요청 헤더)에 전달합니다.

프록시 및 부하 분산 장치가 사용되는 환경에서 Windows 인증 대신 OIDC(OpenID Connect)가 있는 ADFS(Active Directory Federated Services)를 사용할 수 있습니다.

IIS/IIS Express

다음에서 호출 Microsoft.AspNetCore.Authentication.Negotiate 하여 합니다.AddAuthentication

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();

위의 코드는 Razor이 지정된 ASP.NET Core Pages 템플릿에서 생성되었습니다.

시작 설정(디버거)

시작 설정에 대한 구성은 IIS Express용 Properties/launchSettings.json 파일에만 영향을 미치며 Windows 인증용 IIS를 구성하지 않습니다. 서버 구성은 IIS 섹션에 설명되어 있습니다.

Visual Studio 또는 .NET CLI를 통해 사용할 수 있는 웹 애플리케이션 템플릿은 파일을 자동으로 업데이트하는 Windows 인증을 Properties/launchSettings.json 지원하도록 구성할 수 있습니다.

Visual Studio

새 프로젝트

Razor Pages 또는 MVC 앱을 새로 만듭니다. 추가 정보 대화 상자에서 인증 유형을 Windows로 설정합니다.

앱을 실행합니다. 사용자 이름은 렌더링된 앱의 사용자 인터페이스에 표시됩니다.

기존 프로젝트

이 프로젝트의 속성은 Windows 인증을 사용하도록 설정하고 익명 인증은 사용하지 않도록 설정합니다. 프로필 시작 대화 상자를 엽니다.

1. 솔루션 탐색기에서 프로젝트를 마우스 오른쪽 단추로 클릭하고 속성을 선택합니다.
2. 디버그 > 일반 탭을 선택하고 디버그 시작 프로필 UI 열기를 선택합니다.
3. 익명 인증 사용 확인란의 선택을 취소합니다.
4. Windows 인증 사용 확인란을 선택합니다.

또는 iisSettings 파일의 launchSettings.json 노드에서 속성을 구성할 수 있습니다.

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

.NET CLI

새 프로젝트

dotnet new 명령을 webapp 인수(ASP.NET Core Web App)와 --auth Windows 스위치를 사용하여 실행합니다.

dotnet new webapp --auth Windows

기존 프로젝트

iisSettings 파일의 launchSettings.json 노드를 업데이트합니다.

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

IIS

IIS에서는 ASP.NET Core Module을 사용하여 ASP.NET Core 앱을 호스트합니다. Windows 인증은 web.config 파일을 통해 IIS에 대해 구성됩니다. 다음 섹션에서는 다음 방법을 보여줍니다.

• 앱이 배포될 때 서버에서 Windows 인증을 활성화하는 로컬 web.config 파일 제공하기
• IIS 관리자를 사용하여 서버에 이미 배포된 ASP.NET Core 앱의 web.config 파일을 구성하기

아직 이렇게 수행하지 않은 경우 IIS를 사용하도록 설정하여 ASP.NET Core 앱을 호스트합니다. 자세한 내용은 IIS가 있는 Windows에서 ASP.NET Core 호스팅을 참조하세요.

Windows 인증에 IIS 역할 서비스를 사용하도록 설정합니다. 자세한 내용은 IIS 역할 서비스에서 Windows 인증 사용 설정하기(2단계 참조)를 참조하세요.

IIS 통합 미들웨어는 기본적으로 요청을 자동으로 인증하도록 구성됩니다. 자세한 내용은 IIS가 있는 Windows에서 ASP.NET Core 호스팅: IIS 옵션(AutomaticAuthentication)을 참조하세요.

ASP.NET Core 모듈은 기본적으로 Windows 인증 토큰을 앱에 전달하도록 구성됩니다. 자세한 내용은 ASP.NET Core 모듈 구성 참조: aspNetCore 요소의 특성을 참조하세요.

다음 방식 중 하나를 사용합니다.

• 프로젝트를 게시하고 배포하기 전에 프로젝트 루트에 다음 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>
  

  .NET SDK에서 프로젝트를 게시할 때(프로젝트 파일에 속성이 <IsTransformWebConfigDisabled> 설정 true 되지 않은 경우) 게시된 web.config 파일에는 섹션이 <location><system.webServer><security><authentication> 포함됩니다. 속성에 대한 <IsTransformWebConfigDisabled> 자세한 내용은 web.config 파일을 참조하세요.

• 프로젝트를 게시하고 배포한 후 IIS 관리자를 사용하여 서버 쪽 구성을 수행합니다.

  1. IIS 관리자에서 연결 사이드바의 사이트 노드 아래에서 IIS 사이트를 선택합니다.
  2. IIS 영역에서 인증을 두 번 클릭합니다.
  3. 익명 인증을 선택합니다. 작업 사이드바에서 사용 안 함을 선택합니다.
  4. Windows 인증을 선택합니다. 작업 사이드바에서 사용을 선택합니다.

  이러한 작업이 수행되면 IIS 관리자에서 앱의 web.config 파일을 수정합니다. <system.webServer><security><authentication> 및 anonymousAuthentication의 설정이 업데이트되면서 windowsAuthentication 노드가 추가됩니다.

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

  <system.webServer> IIS 관리자가 web.config 파일에 추가한 섹션은 앱이 게시될 때 .NET SDK에서 추가한 앱 <location> 섹션 외부에 있습니다. 섹션이 <location> 노드 외부에 추가되므로 설정은 현재 앱의 하위 앱에 상속됩니다. 상속을 방지하려면, .NET SDK가 제공한 섹션 안으로 <security> 추가 섹션을 이동하세요.

  IIS 관리자를 사용하여 IIS 구성을 추가하는 경우 서버에 있는 앱의 web.config 파일에만 영향을 줍니다. 서버의 web.config 복사본이 프로젝트의 web.config 파일로 대체되면 다음번에 앱이 배포될 때 서버에 있는 설정을 덮어쓸 수 있습니다. 다음 방법 중 하나를 사용하여 설정을 관리합니다.

  • 배포 시 web.config 파일이 덮어쓰기되면 IIS 관리자를 사용하여 해당 파일의 설정을 다시 설정합니다.
  • 설정을 사용하여 로컬로 앱에 web.config 파일을 추가합니다.

Kestrel

Microsoft.AspNetCore.Authentication.Negotiate NuGet 패키지를 사용하여 Kestrel Windows, Linux 및 macOS에서 Negotiate 및 Kerberos를 사용하여 Windows 인증을 사용하도록 설정할 수 있습니다.

Warning

자격 증명은 연결에서 요청 간에 유지될 수 있습니다. 프록시가 Kestrel과 1:1 연결 선호도(영구 연결)를 유지하지 않는 한 협상 인증을 프록시와 함께 사용하면 안 됩니다.

Note

협상 처리기는 원래 서버가 사용 설정되어 있는지, 그리고 기본적으로 Windows 인증을 지원하는지 검색합니다. 서버에서 Windows 인증을 지원하지만 사용하지 않도록 설정되어 있으면 오류가 발생하면서 서버 구현을 사용하도록 설정하라는 메시지가 표시됩니다. 서버에서 Windows 인증을 사용하도록 설정되어 있으면 협상 처리기가 인증 요청을 투명하게 전달합니다.

인증 및 대체 권한 부여 정책은 다음의 강조 표시된 코드에 의해 사용하도록 설정됩니다.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();

위의 코드는 Razor이 지정된 ASP.NET Core Pages 템플릿에서 생성되었습니다.

강조 표시된 선:

• 5-6: AddAuthenticationAddNegotiate 협상 인증 처리기를 등록하고 구성합니다.
• 8-11: AddAuthorization 대체 정책을 사용하여, 기본적으로 인증된 사용자를 적용합니다.
• 26: UseAuthentication 각 요청에 대한 인증 처리기를 실행하고 채웁니다 HttpContext.User.
• 27: UseAuthorization 대체 정책을 포함하여 권한 부여 정책을 평가합니다.

Note

AddAuthentication 및 AddNegotiate를 호출하고 등록하며 구성하여 협상 처리기를 설정합니다. 요청마다 인증을 실행하지 않습니다. 인증 미들웨어(UseAuthentication)는 처리기를 호출하고 HttpContext.User을(를) 채우며, 정책 평가가 작동하려면 반드시 UseAuthorization 앞에 나타나야 합니다.

Kerberos 인증 및 RBAC(역할 기반 액세스 제어)

Linux 또는 macOS의 Kerberos 인증은 인증된 사용자에게 역할 정보를 제공하지 않습니다. Kerberos 사용자에게 역할 및 그룹 정보를 추가하려면 LDAP 도메인에서 역할을 검색하도록 인증 처리기를 구성해야 합니다. 가장 기본적인 구성은 쿼리할 LDAP 도메인만 지정하고 인증된 사용자의 컨텍스트를 사용하여 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");
        }
    });

일부 구성에는 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(settings =>
                {
                    settings.Domain = "contoso.com";
                    settings.MachineAccountName = "machineName";
                    settings.MachineAccountPassword =
                                      builder.Configuration["Password"];
                });
            }
        });

builder.Services.AddRazorPages();

기본적으로 협상 인증 처리기는 중첩된 도메인을 확인합니다. 크거나 복잡한 LDAP 환경에서 중첩된 도메인을 확인하면 조회 속도가 느리거나 각 사용자에 대해 많은 메모리가 사용될 수 있습니다. IgnoreNestedGroups 옵션을 사용하여 중첩된 도메인 확인을 사용하지 않도록 설정할 수 있습니다.

익명 요청이 허용됩니다. ASP.NET Core 권한 부여를 사용하여 익명 인증 요청에 이의를 제기합니다.

Windows 환경 구성

API는Microsoft.AspNetCore.Authentication.Negotiate사용자 모드 인증을 수행합니다. SPN(서비스 사용자 이름)은 컴퓨터 계정이 아닌 서비스를 실행하는 사용자 계정에 추가해야 합니다. 관리 명령 셸에서 setspn -S HTTP/myservername.mydomain.com myuser를 실행합니다.

Kerberos 및 NTLM

ASP.NET Core용 Kestrel 협상 패키지는 NTLM보다 더 안전하고 성능이 좋은 인증 체계인 Kerberos를 사용하려고 시도합니다.

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 은 기본값이므로 Kerberos를 지정합니다.

IIS, IISExpress 및 Kestrel Kerberos 및 NTLM을 모두 지원합니다.

Fiddler와 같은 도구에서 IIS 또는 IISExpress를 사용하여 WWW-Authenticate: 헤더를 검사하면 NTLM이 Negotiate 표시됩니다.

Kestrel 표시만 WWW-Authenticate: Negotiate

헤더는 WWW-Authenticate: Negotiate 서버가 NTLM 또는 Kerberos를 사용할 수 있음을 의미합니다. Kestrel Negotiate 헤더 접두사 필요, 요청 또는 응답 인증 헤더에서 직접 지정 NTLM 을 지원 하지 않습니다. NTLM은 지원 Kestrel되지만 Negotiate.

KestrelNTLM 또는 Kerberos가 사용되는지 확인하기 위해 Base64에서 헤더를 디코딩하고 표시하거나 NTLM표시 HTTP 합니다. HTTP 은 Kerberos가 사용되었음을 나타냅니다.

Linux 및 macOS 환경 구성

Linux 또는 macOS 컴퓨터를 Windows 도메인에 조인하기 위한 지침은 Windows 인증 - Kerberos를 사용하여 Azure Data Studio를 SQL Server에 연결 문서에서 확인할 수 있습니다. 해당 지침을 통해 도메인에서 Linux 컴퓨터의 컴퓨터 계정을 만들 수 있습니다. SPN을 해당 컴퓨터 계정에 추가해야 합니다.

Note

Windows 인증 - Kerberos를 사용하여 Azure Data Studio를 SQL Server에 연결 문서의 지침을 따를 때 필요한 경우 python-software-properties를 python3-software-properties로 바꿉니다.

Linux 또는 macOS 컴퓨터가 도메인에 조인되면 SPN과 함께 keytab 파일을 제공하기 위한 추가 단계가 필요합니다.

• 도메인 컨트롤러에서 컴퓨터 계정에 새 웹 서비스 SPN을 추가합니다.
  • setspn -S HTTP/mywebservice.mydomain.com mymachine
  • setspn -S HTTP/mywebservice@MYDOMAIN.COM mymachine
• ktpass를 사용하여 keytab 파일을 생성합니다.
  • 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
  • 일부 필드는 표시된 대로 대문자로 지정해야 합니다.
• keytab 파일을 Linux 또는 macOS 컴퓨터에 복사합니다.
• 환경 변수 export KRB5_KTNAME=/tmp/mymachine.HTTP.keytab을 통해 keytab 파일을 선택합니다.
• klist를 호출하여 현재 사용할 수 있는 SPN을 표시합니다.

Note

keytab 파일에는 도메인 액세스 자격 증명이 포함되어 있으며 그에 따라 보호되어야 합니다.

HTTP.sys

HTTP.sys는 협상, NTLM 또는 기본 인증을 사용하는 커널 모드 Windows 인증을 지원합니다.

다음 코드를 통해 인증을 추가하고 Windows 인증에서 HTTP.sys를 사용하도록 앱의 웹 호스트를 구성합니다.

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는 Kerberos 인증 프로토콜을 사용하여 커널 모드 인증에 위임합니다. 사용자 모드 인증은 Kerberos 및 HTTP.sys로 지원되지 않습니다. 머신 계정은 Active Directory에서 가져온 Kerberos 토큰/티켓의 암호를 해독하는 데 사용되고 사용자를 인증하는 서버에 클라이언트에 의해 전달되어야 합니다. 앱의 사용자가 아닌 호스트에 대해 SPN(서비스 사용자 이름)을 등록합니다.

Note

HTTP.sys는 Nano Server 버전 1709 이상에서는 지원되지 않습니다. Nano Server에서 Windows 인증 및 HTTP.sys 사용하려면 Server Core(microsoft/windowsservercore) 컨테이너(참조 https://hub.docker.com/_/microsoft-windows-servercore)를 사용합니다. Server Core에 대한 자세한 내용은 Windows Server의 Server Core 설치 옵션은 무엇인가요?를 참조하세요.

사용자에게 권한 부여

익명 액세스의 구성 상태가 [Authorize] 및 [AllowAnonymous] 특성이 앱에서 사용되는 방식을 결정합니다. 다음 두 섹션에서는 익명 액세스의 허용되지 않는 구성 상태와 허용되는 구성 상태를 처리하는 방법을 설명합니다.

익명 액세스 허용 안 함

Windows 인증을 사용하도록 설정하고 익명 액세스를 사용하지 않도록 설정하면 [Authorize] 및 [AllowAnonymous] 특성이 적용되지 않습니다. IIS 사이트가 익명 액세스를 허용하지 않도록 구성된 경우 요청이 앱에 도달하지 않습니다. 이러한 이유로 [AllowAnonymous] 특성을 적용할 수 없습니다.

익명 액세스 허용

Windows 인증과 익명 액세스를 모두 사용하도록 설정하는 경우 [Authorize] 및 [AllowAnonymous] 특성을 사용합니다. [Authorize] 특성을 사용하면 인증이 필요한 앱의 엔드포인트를 보호할 수 있습니다. [AllowAnonymous] 특성은 익명 액세스를 허용하는 앱에서 [Authorize] 특성을 재정의합니다. 특성 사용에 대한 자세한 내용은 ASP.NET Core의 단순 권한 부여를 참조하세요.

Note

기본적으로 페이지에 액세스할 수 있는 권한이 없는 사용자에게는 빈 HTTP 403 응답이 표시됩니다. StatusCodePages 미들웨어를 사용자에게 더 나은 ‘액세스 거부’ 경험 제공하도록 구성할 수 있습니다.

Impersonation

ASP.NET Core는 가장을 구현하지 않습니다. 앱은 앱 풀 또는 프로세스 ID를 사용하여 모든 요청에 대해 앱의 ID로 실행됩니다. 앱이 사용자를 대신하여 작업을 수행해야 할 경우에는 WindowsIdentity.RunImpersonated의 RunImpersonatedAsync에서 또는 Program.cs을 사용하십시오. 이 컨텍스트에서 단일 작업을 실행한 다음 컨텍스트를 닫습니다.

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 Windows, Linux 및 macOS에서 인증을 사용하도록 설정하지만 가장은 Windows에서만 지원됩니다.

클레임 전환

IIS로 호스팅하는 경우 사용자를 초기화하기 위해 AuthenticateAsync를 내부적으로 호출하지 않습니다. 따라서 모든 인증 후에 클레임을 변환하는 데 사용되는 IClaimsTransformation 구현은 기본적으로 활성화되지 않습니다. 클레임 변환을 활성화하는 코드 예제 및 자세한 내용은 In-Process 호스팅과 Out-of-process 호스팅 간의 차이점을 참조하세요.

추가 리소스

• dotnet 게시
• IIS가 있는 Windows에서 ASP.NET Core 호스팅
• IIS용 ANCM(ASP.NET Core 모듈)
• ASP.NET Core 앱 배포용 Visual Studio 게시 프로필(.pubxml)