권한부여: 사용자 지정 정책 기반 권한부여
- 본 번역문서의 원문은 Custom Policy-Based Authorization docs.microsoft.com 입니다.
- 본 번역문서는 ASP.NET Core 보안 : 사용자 지정 정책 기반 권한부여 www.taeyo.net 에서도 함께 제공됩니다.
내부적으로 역할 기반 권한부여와 클레임 기반 권한부여는 요구사항(Requirements)과 해당 요구사항에 대한 처리기, 그리고 미리 구성된 정책으로 구성됩니다. 이런 구성 요소들을 활용함으로써 권한부여 평가를 코드로 표현할 수 있으며, 풍부하고 재사용 가능한, 손쉽게 테스트할 수 있는 권한부여 구조를 만들어낼 수 있습니다.
권한부여 정책은 하나 이상의 요구사항으로 구성되며, 응용 프로그램 구동 시에 Startup.cs 파일의 ConfigureServices
메서드에서 Authorization 서비스 구성의 일부로 등록됩니다.
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc();
services.AddAuthorization(options =>
{
options.AddPolicy("Over21",
policy => policy.Requirements.Add(new MinimumAgeRequirement(21)));
});
}
이 코드는 요구사항을 추가하는 Add
메서드에 매개변수로 최소 연령을 지정하는 단일 요구사항을 전달함으로써 "Over21"이라는 정책을 생성하고 있습니다.
이렇게 등록된 정책은 다음과 같이 Authorize
어트리뷰트에 정책 이름을 지정하여 적용합니다:
[Authorize(Policy="Over21")]
public class AlcoholPurchaseRequirementsController : Controller
{
public ActionResult Login()
{
}
public ActionResult Logout()
{
}
}
요구사항
권한부여 요구사항은 정책이 현재 사용자 신원을 평가하기 위해 사용할 수 있는 데이터 매개변수들의 모음입니다.
본문의 최소 연령 정책의 경우, 요구사항은 단 하나의 매개변수, 즉 최소 연령만을 필요로 합니다.
요구사항은 IAuthorizationRequirement
인터페이스를 구현해야 하며, 이 인터페이스는 빈 마커 인터페이스입니다.
매개변수화 된 최소 연령 요구사항은 다음과 같이 구현될 수 있습니다:
public class MinimumAgeRequirement : IAuthorizationRequirement
{
public MinimumAgeRequirement(int age)
{
MinimumAge = age;
}
protected int MinimumAge { get; set; }
}
그러나 요구사항에 데이터나 속성이 반드시 필요한 것은 아닙니다.
권한부여 처리기
권한부여 처리기는 요구사항의 속성을 평가합니다.
권한부여 처리기는 제공된 AuthorizationHandlerContext
를 대상으로 평가를 수행하고 권한 허용 여부를 결정해야 합니다.
하나의 요구사항에는 다수의 처리기가 존재할 수 있습니다.
처리기는 AuthorizationHandler<T>
형식을 상속 받아야하며, 여기서 T는 처리기가 처리해야 할 요구사항입니다.
최소 연령 처리기는 다음과 같이 구현될 수 있습니다:
public class MinimumAgeHandler : AuthorizationHandler<MinimumAgeRequirement>
{
protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, MinimumAgeRequirement requirement)
{
if (!context.User.HasClaim(c => c.Type == ClaimTypes.DateOfBirth &&
c.Issuer == "http://contoso.com"))
{
// .NET 4.x -> return Task.FromResult(0);
return Task.CompletedTask;
}
var dateOfBirth = Convert.ToDateTime(context.User.FindFirst(
c => c.Type == ClaimTypes.DateOfBirth && c.Issuer == "http://contoso.com").Value);
int calculatedAge = DateTime.Today.Year - dateOfBirth.Year;
if (dateOfBirth > DateTime.Today.AddYears(-calculatedAge))
{
calculatedAge--;
}
if (calculatedAge >= requirement.MinimumAge)
{
context.Succeed(requirement);
}
return Task.CompletedTask;
}
}
이 예제 코드는 먼저 사용자의 신원이 우리가 알고 있고 신뢰할 수 있는 발급자로부터 발급된 생년월일 클레임을 갖고 있는지부터 확인합니다.
만약 클레임이 존재하지 않는다면 권한을 부여할 수 없으므로 그냥 반환됩니다.
클레임이 존재하면 사용자의 나이를 계산하고, 나이가 요구사항을 통해서 전달된 최소 연령을 만족할 경우에만 권한부여에 성공하게 됩니다.
권한부여가 성공하면 context.Succeed()
메서드에 성공한 요구사항을 매개변수로 전달하여 호출합니다.
처리기는 다음과 같이 구성 과정 중 서비스 컬렉션에 등록되어야 합니다:
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc();
services.AddAuthorization(options =>
{
options.AddPolicy("Over21",
policy => policy.Requirements.Add(new MinimumAgeRequirement(21)));
});
services.AddSingleton<IAuthorizationHandler, MinimumAgeHandler>();
}
각각의 처리기는 services.AddSingleton<IAuthorizationHandler, YourHandlerClass>();
에 처리기 클래스를 전달해서 서비스 컬렉션에 추가됩니다.
처리기가 반환해야 하는 결과는?
본문의 처리기 예제를 살펴보면 Handle
메서드에 반환값이 존재하지 않음을 알 수 있습니다.
그렇다면 성공 혹은 실패 여부는 어떻게 결정할 수 있을까요?
-
처리기는 성공적으로 검증된 요구사항을
context.Succeed(IAuthorizationRequirement requirement)
메서드에 매개변수로 전달하여 호출함으로써 성공했음을 나타냅니다. -
일반적으로 처리기는 실패를 처리할 필요가 없는데, 동일한 요구사항에 대한 다른 처리기가 성공할 수도 있기 때문입니다.
-
다른 처리기의 성공 여부와 관계없이 무조건 실패한 것으로 나타내려면
context.Fail
메서드를 호출합니다.
정책에서 특정 요구사항을 필요로 할 경우, 처리기 내부에서 성공이나 실패를 표시하기 위해 어떤 메서드를 호출했는지와는 무관하게, 해당 요구사항과 관련된 모든 처리기들이 호출됩니다.
결과적으로 다른 처리기에서 context.Fail()
메서드가 호출된 경우에도, 로깅 같은 요구사항의 부수적인 작업들은 항상 수행됩니다.
요구사항에 대해 여러 개의 처기리가 필요한 이유
만약, OR 기반의 평가를 수행하고 싶다면 단일 요구사항을 대상으로 여러 개의 처리기를 구현해야 합니다. 가령, Microsoft에는 키 카드로만 열 수 있는 문이 있습니다. 만약 키 카드를 집에 두고 왔다면, 접수원이 임시 스티커를 인쇄해서 대신 문을 열어줍니다. 이 시나리오의 경우, 요구사항은 EnterBuilding 하나지만 여러 가지 처리기가 해당 요구사항을 개별적으로 검토하게 됩니다.
public class EnterBuildingRequirement : IAuthorizationRequirement
{
}
public class BadgeEntryHandler : AuthorizationHandler<EnterBuildingRequirement>
{
protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, EnterBuildingRequirement requirement)
{
if (context.User.HasClaim(c => c.Type == ClaimTypes.BadgeId &&
c.Issuer == "http://microsoftsecurity"))
{
context.Succeed(requirement);
}
return Task.CompletedTask;
}
}
public class HasTemporaryStickerHandler : AuthorizationHandler<EnterBuildingRequirement>
{
protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, EnterBuildingRequirement requirement)
{
if (context.User.HasClaim(c => c.Type == ClaimTypes.TemporaryBadgeId &&
c.Issuer == "https://microsoftsecurity"))
{
// We'd also check the expiration date on the sticker.
context.Succeed(requirement);
}
return Task.CompletedTask;
}
}
두 처리기가 모두 등록되어 있다고 가정할 경우, 정책이 EnterBuildingRequirement
를 평가할 때 두 처리기 중 하나라도 성공하면 정책 평가가 성공한 것으로 간주됩니다.
func를 이용해서 정책 구성하기
코드로 정책을 표현해서 구성하는 편이 더 간단한 경우도 있습니다.
정책을 구성할 때 RequireAssertion
정책 빌더를 이용해서 Func<AuthorizationHandlerContext, bool>
을 전달하기만 하면 됩니다.
가령, 이전 절에서 살펴본 BadgeEntryHandler
는 다음과 같이 재작성할 수 있습니다:
services.AddAuthorization(options =>
{
options.AddPolicy("BadgeEntry",
policy => policy.RequireAssertion(context =>
context.User.HasClaim(c =>
(c.Type == ClaimTypes.BadgeId ||
c.Type == ClaimTypes.TemporaryBadgeId)
&& c.Issuer == "https://microsoftsecurity"));
}));
}
}
역주
위 예제의 괄호, 중괄호, 세미콜론은 완전히 엉망으로 작성되어 있으며 GitHub에서 제공되는 예제 코드들 중에서도 올바른 코드를 발견할 수 없습니다. 본 문단에서 전달하고자 하는 내용만 감안하여 살펴보시기 바랍니다.
처리기에서 MVC 요청 컨텍스트 접근하기
권한부여 처리기를 작성할 때 반드시 구현해야 하는 Handle
메서드에는 AuthorizationContext
와 처리하려는 Requirement
, 이렇게 두 가지 매개변수가 전달됩니다.
MVC나 JabbR 같은 프레임워크는 AuthorizationContext
의 Resource
속성에 추가적인 정보를 전달하기 위해서 자유롭게 개체를 추가할 수 있습니다.
예를 들어서, MVC는 HttpContext나 RouteData를 비롯한, MVC가 제공해주는 다양한 정보들에 접근하기 위한 용도로 사용되는 Microsoft.AspNetCore.Mvc.Filters.AuthorizationFilterContext
의 인스턴스를 Resource
속성에 전달합니다.
이 Resource
속성을 사용하는 방법은 프레임워크에 따라서 달라집니다.
그리고 Resource
속성의 정보를 주의해서 사용하지 않으면 권한부여 정책이 특정 프레임워크에 제한될 수 있습니다.
따라서 먼저 as
키워드를 사용해서 Resource
속성의 형변환을 시도한 다음, 형변환이 성공했는지 여부를 확인해서 처리기가 다른 프레임워크에서 실행될 때 InvalidCastExceptions
예외가 발생하지 않도록 주의해야 합니다:
var mvcContext = context.Resource as Microsoft.AspNetCore.Mvc.Filters.AuthorizationFilterContext;
if (mvcContext != null)
{
// Examine MVC specific things like routing data.
}
- 권한부여: 개요 2017-01-14 08:00
- 권한부여: 간단한 권한부여 2017-01-14 11:00
- 권한부여: 역할 기반 권한부여 2017-01-14 14:00
- 권한부여: 클레임 기반 권한부여 2017-01-15 08:00
- 권한부여: 사용자 지정 정책 기반 권한부여 2017-01-15 11:00
- 권한부여: 요구사항 처리기와 의존성 주입 2017-01-15 14:00
- 권한부여: 리소스 기반 권한부여 2017-01-16 08:00
- 권한부여: 뷰 기반 권한부여 2017-01-16 11:00
- 권한부여: 스키마별 신원 제한 2017-01-16 14:00
- 인증: ASP.NET Core Identity 살펴보기 2017-01-30 08:00
- 인증: Facebook, Google 및 기타 외부 공급자를 이용한 인증 활성화시키기 2017-02-13 08:00
- 인증: Facebook 인증 구성하기 2017-02-13 11:00
- 인증: Twitter 인증 구성하기 2017-02-20 08:00
- 인증: Google 인증 구성하기 2017-02-20 11:00
- 인증: Microsoft 계정 인증 구성하기 2017-02-20 14:00
- 인증: 계정 확인 및 비밀번호 복구 2017-03-06 08:00
- 인증: SMS를 이용한 2단계 인증 2017-03-13 08:00
- 인증: ASP.NET Core Identity 없이 Cookie 미들웨어 사용하기 2017-03-20 08:00
- 데이터 보호: 데이터 보호 개요 2017-03-27 08:00
- 데이터 보호: 데이터 보호 API 시작하기 2017-03-29 08:00
- 데이터 보호: 소비자 APIs 개요 2017-03-31 08:00
- 데이터 보호: 용도 문자열 2017-04-03 08:00
- 데이터 보호: ASP.NET Core의 용도 계층 구조 및 다중-테넌트(Multi-Tenancy) 2017-04-05 08:00
- 데이터 보호: 비밀번호 해싱 2017-04-07 08:00
- 데이터 보호: 보호된 페이로드의 수명 제한하기 2017-04-10 08:00
- 테이터 보호: 키가 취소된 페이로드의 보호 해제하기 2017-04-12 08:00
- 데이터 보호: 데이터 보호 구성하기 2017-04-14 08:00
- 데이터 보호: 키 관리 및 수명 기본 설정 2017-04-17 08:00
- 데이터 보호: 머신 수준 정책 2017-04-19 08:00
- 데이터 보호: 비-DI 인식 시나리오 2017-04-21 08:00
- 호환성: 응용 프로그램 간 인증 쿠키 공유하기 2017-05-12 08:00
- 호환성: ASP.NET의 <machineKey> 요소 대체하기 2017-05-16 08:00
- 교차 원본 요청 활성화시키기 (CORS) 2017-05-17 08:00
- ASP.NET Core 응용 프로그램에 SSL 적용하기 2017-05-18 08:00
- 개발 중 민감한 응용 프로그램 정보 안전하게 저장하기 2017-05-19 08:00