ASP.NET ID의 역할과 클레임에 대한 모범 사례

저는 claimsin 사용에 완전히 익숙하지 ASP.NETIdentity않으며 사용에 대한 모범 사례에 대한 아이디어를 얻고 싶습니다 Roles and/or Claims.

이 모든 것을 읽은 후에도 여전히 질문이 있습니다.

Q : 더 이상 역할을 사용하지 않습니까?
Q : 그렇다면 역할이 계속 제공되는 이유는 무엇입니까?
Q : 클레임 만 사용해야합니까?
Q : 역할 및 클레임을 함께 사용해야합니까?

나의 초기 생각은 우리가 그것들을 함께 사용해야 만한다는 것입니다. 나는 그들이 지원 Claims하는 하위 카테고리로 Roles봅니다.

예 :
역할 : 회계
클레임 : CanUpdateLedger, CanOnlyReadLedger, CanDeleteFromLedger

Q : 상호 배타적입니까?
Q : 아니면 클레임 만 진행하고 클레임에 "완전히 자격을 부여"하는 것이 더 낫습니까?
Q : 여기서 모범 사례는 무엇입니까?

예 : 역할 및 클레임 함께 사용
물론,이를 위해 고유 한 속성 논리를 작성해야합니다.

[Authorize(Roles="Accounting")]
[ClaimAuthorize(Permission="CanUpdateLedger")]
public ActionResult CreateAsset(Asset entity)
{
    // Do stuff here

    return View();
}

예 : 클레임에 대한 완전한 자격 부여

[ClaimAuthorize(Permission="Accounting.Ledger.CanUpdate")]
public ActionResult CreateAsset(Asset entity)
{
    // Do stuff here

    return View();
}

역할은 동일한 수준의 보안 권한을 공유하는 사용자를 모으는 상징적 범주입니다. 역할 기반 권한은 먼저 사용자를 식별 한 다음 사용자가 할당 된 역할을 확인하고 마지막으로 해당 역할을 자원에 액세스 할 수있는 권한이있는 역할과 비교해야합니다.

반대로 클레임은 그룹 기반이 아니라 신원 기반입니다.

에서 Microsoft 설명서 :

ID가 생성되면 신뢰할 수있는 당사자가 발급 한 하나 이상의 클레임이 할당 될 수 있습니다. 클레임은 주체가 할 수있는 것이 아니라 주체가 무엇인지 나타내는 이름 값 쌍입니다.

보안 검사는 나중에 하나 이상의 클레임 값을 기반으로 리소스 액세스 권한을 결정할 수 있습니다.

두 가지를 함께 사용하거나 일부 상황에서 한 유형을 사용하고 다른 상황에서 다른 유형을 사용할 수 있습니다 . 대부분 다른 시스템과의 상호 운용 및 관리 전략에 따라 다릅니다. 예를 들어, 특정 클레임이 할당 된 사용자를 관리하는 것보다 관리자가 역할에 할당 된 사용자 목록을 관리하는 것이 더 쉬울 수 있습니다. 클레임은 클라이언트에 클레임을 할당 할 수있는 RESTful 시나리오에서 매우 유용 할 수 있으며 클라이언트는 모든 요청에 ​​대해 사용자 이름과 암호를 전달하는 대신 권한 부여를 위해 클레임을 제시 할 수 있습니다.

@Claies가 완벽하게 설명했듯이 클레임은보다 설명적이고 깊은 역할을 할 수 있습니다. 나는 그것들을 당신의 역할 ID로 생각합니다. 헬스장 아이디가있어서 멤버 역할에 속합니다. 나는 또한 킥복싱 레슨에 참여하고 있으므로 그들에 대한 킥복싱 ID 클레임을 가지고 있습니다. 내 신청서에는 회원권에 맞는 새로운 역할을 선언해야합니다. 대신 많은 새로운 멤버십 유형 대신 내가 속한 각 그룹 클래스에 대한 ID가 있습니다. 그래서 클레임이 나에게 더 적합합니다.

역할에 대한 클레임 사용의 이점에 대해 이야기하는 Barry Dorrans의 훌륭한 설명 비디오가 있습니다. 그는 또한 이전 버전과의 호환성을 위해 역할이 여전히 .NET에 있다고 말합니다. 이 비디오는 클레임, 역할, 정책, 권한 부여 및 인증이 작동하는 방식에 대해 매우 유익합니다.

여기에서 찾을 수 있습니다 : Barr Dorrans를 사용한 ASP.NET Core 인증

수십 년 동안 다양한 인증 및 권한 부여 기술을 사용해온 현재 MVC 응용 프로그램은 다음 방법을 사용합니다.

클레임은 모든 승인에 사용됩니다. 사용자에게 하나의 역할이 할당됩니다 (여러 역할이 가능하지만 필요하지 않음). 아래에서 더 자세히 알아보세요.

일반적으로 A ClaimsAuthorize 속성 클래스가 사용됩니다. 대부분의 컨트롤러 작업은 CRUD이므로 모든 컨트롤러 작업을 반복하고 읽기 / 편집 / 만들기 / 삭제의 각 컨트롤러 작업 속성에 대한 클레임 유형을 만드는 코드 우선 데이터베이스 생성 루틴이 있습니다. 예 :

[ClaimsAuthorize("SomeController", "Edit")]
[HttpPost]

MVC 뷰에서 사용하기 위해 기본 컨트롤러 클래스는 뷰 백 항목을 제공합니다.

        protected override void OnActionExecuting(ActionExecutingContext filterContext)
        {
            // get user claims
            var user = filterContext.HttpContext.User as System.Security.Claims.ClaimsPrincipal;

            if (user != null)
            {
                // Get all user claims on this controller. In this controler base class, [this] still gets the descendant instance type, hence name
                List<Claim> claims = user.Claims.Where(c => c.Type == this.GetType().Name).ToList();

                // set Viewbag with default authorisations on this controller
                ViewBag.ClaimRead = claims.Any(c => c.Value == "Read");
                ViewBag.ClaimEdit = claims.Any(c => c.Value == "Edit");
                ViewBag.ClaimCreate = claims.Any(c => c.Value == "Create");
                ViewBag.ClaimDelete = claims.Any(c => c.Value == "Delete");
            }

            base.OnActionExecuting(filterContext);
        }

웹 사이트 메뉴 및 기타 비 컨트롤러 작업에 대해 다른 주장이 있습니다. 예 : 사용자가 특정 통화 필드를 볼 수 있는지 여부.

bool UserHasSpecificClaim(string claimType, string claimValue)
{
    // get user claims
    var user = this.HttpContext.User as System.Security.Claims.ClaimsPrincipal;

    if (user != null)
    {
        // Get the specific claim if any
        return user.Claims.Any(c => c.Type == claimType && c.Value == claimValue);
    }

    return false;
}

public bool UserHasTradePricesReadClaim
{
    get
    {
        return UserHasSpecificClaim("TradePrices", "Read");
    }
}

그렇다면 역할은 어디에 적합합니까?

역할을 (기본) 클레임 집합에 연결하는 테이블이 있습니다. 사용자 권한을 설정할 때 기본값은 사용자에게 역할에 대한 클레임을 제공하는 것입니다. 각 사용자는 기본값보다 더 많거나 적은 클레임을 가질 수 있습니다. 편집을 간단하게하기 위해 클레임 목록은 컨트롤러 및 작업 (연속)별로 표시되고 다른 클레임이 나열됩니다. 버튼은 약간의 자바 스크립트와 함께 사용되어 클레임을 선택하는 데 필요한 "클릭"을 최소화하기 위해 일련의 작업을 선택합니다. 저장시 사용자 클레임이 삭제되고 선택한 클레임이 모두 추가됩니다. 웹 애플리케이션은 클레임을 한 번만로드하므로 모든 변경 사항은이 정적 데이터 내에서 다시로드하라는 메시지를 표시해야합니다.

따라서 관리자는 각 역할에있는 클레임과 역할 및 기본 클레임으로 설정 한 후 사용자가 갖는 클레임을 선택할 수 있습니다. 시스템에는 사용자 수가 적기 때문에이 데이터를 관리하는 것은 간단합니다.

역할과 클레임의 차이를 이해하기 위해 역할의 한계에 직면하고 클레임이이 문제를 어떻게 처리하는지 느끼기 위해 역할이이 문제를 해결할 수없는 클레임의 힘을 인식 할 수있는 두 가지 시나리오를 제공합니다.

1- 귀하의 사이트에는 두 개의 모듈 (페이지, 서비스 ..etc)이 있어야합니다. 첫 번째 모듈은 어린이 (18 세 미만), 다른 하나는 성인 (18 세 이상) 사용자 ID에 생일 청구가 있습니다.

이 클레임에 대한 정책을 만들어야 각 모듈에 대한 권한이이 값에 부여되고 사용자의 연령이 18 세를 넘으면이 연령 이전이 아닌 성인 모듈로 이동할 수 있습니다.

역할은 가질 수있는 부울 데이터 유형입니다. 역할 역할에 잘못된 값이 없습니다.

2- 사이트에 역할 사용자가 있고 코드를 변경하지 않고 유지 관리를 위해 사용자의 액세스를 방지하고 싶지 않습니다.

클레임에서 진정한 사용자가 페이지를 볼 수없는 경우 역할 사용자에 대한 속성 권한을 부여하는 UnderConstrain 정책을 만들 수 있습니다.