답변:
ASP.NET MVC 컨텍스트에서 클레임 기반 액세스 제어의 이점을 얻을 수있는 방법을 보여 드리겠습니다.
역할 기반 인증을 사용하는 경우 고객 작성 조치가 있고 '판매'역할을 수행하는 사람들이이를 수행 할 수있게하려면 다음과 같은 코드를 작성하십시오.
[Authorize(Roles="Sale")]
public ActionResult CreateCustomer()
{
return View();
}나중에 '마케팅'역할을 가진 사람들이 고객을 만들 수 있어야한다는 것을 깨달았습니다. 그런 다음 Action 메소드를 다음과 같이 업데이트하십시오.
[Authorize(Roles = "Sale", "Marketing")]
public ActionResult CreateCustomer()
{
return View();
}이제 일부 마케팅 담당자가 고객을 작성할 수 없어야하지만 마케팅 담당자에게 다른 역할을 지정할 수는 없다는 것을 깨달았습니다. 따라서 모든 마케팅 담당자가 고객을 만들 수 있도록해야합니다.
마케팅 담당자가 고객을 작성하도록 허용하기로 결정할 때마다 다른 문제점을 발견 한 경우 모든 MVC 조치 메소드 권한 부여 속성을 업데이트하고 애플리케이션을 컴파일하고 테스트 및 배치해야합니다. 며칠 후 마케팅이 아니라 다른 역할이 작업을 수행하도록 결정 했으므로 코드베이스를 검색하고 권한 부여 속성에서 모든 '마케팅'을 삭제하고 권한 부여 속성에 새 역할 이름을 추가하십시오. 건강한 솔루션. 이 시점에서 권한 기반 액세스 제어가 필요하다는 것을 알 수 있습니다.
권한 기반 액세스 제어는 다양한 사용자에게 다양한 권한을 할당하고 사용자가 런타임시 코드에서 조치를 실행할 권한이 있는지 확인하는 방법입니다. 다양한 사용자에게 다양한 권한을 할당 한 후 사용자에게 "Facebook User", "Long time User"등과 같은 속성이있는 경우 일부 사용자가 일부 코드를 실행하도록 허용해야한다는 사실을 알게되었습니다. 예를 들어 보겠습니다. 사용자가 Facebook을 사용하여 로그인 한 경우 특정 페이지에 대한 액세스를 허용한다고 가정하십시오. 이제 해당 사용자에 대한 권한 'Facebook'을 작성 하시겠습니까? 아니요, 'Facebook'은 권한처럼 들리지 않습니다. 그렇습니까? 오히려 그것은 주장처럼 들립니다. 동시에 권한도 소유권 주장처럼 들릴 수 있습니다! 따라서 클레임을 확인하고 액세스를 허용하는 것이 좋습니다.
이제 클레임 기반 액세스 제어의 구체적인 예로 돌아가 보겠습니다.
다음과 같이 클레임 집합을 정의 할 수 있습니다.
"CanCreateCustomer", "CanDeleteCustomer", "CanEditCustomer"등.
이제 액션 메소드를 다음과 같이 장식 할 수 있습니다 :
[ClaimAuthorize(Permission="CanCreateCustomer")]
public ActionResult CreateCustomer()
{
return View();
}([ClaimAuthorize (Permission = "CanCreateCustomer")]는 MVC 클래스 라이브러리에 내장되어 있지 않을 수 있습니다. 예를 보여 드리기 위해 이러한 속성 클래스 정의가있는 클래스 라이브러리를 사용할 수 있습니다)
이제 CreateCustomer 작업 메소드에는 항상 'CanCreateCustomer'권한이 필요하며 절대 변경되지 않거나 거의 변경되지 않음을 알 수 있습니다. 따라서 데이터베이스에서 권한 테이블 (청구) 및 사용자 권한 관계를 작성합니다. 관리자 패널에서 작업을 수행 할 수있는 각 사용자에 대한 권한 (클레임)을 설정할 수 있습니다. 'CanCreateCustomer'권한 (클레임)을 원하는 사람에게 할당 할 수 있으며 허용 된 사용자 만 고객을 만들 수 있으며 허용 된 사용자는 고객 만 만들 수 있으며 다른 권한을 동일한 사용자에게 할당하지 않는 한 아무 것도 만들 수 없습니다.
이 보안 모델은 깨끗한 코드 연습을 제공합니다. 또한 작업 방법을 작성할 때이 방법을 사용할 수있는 사람에 대해 생각할 필요가 없으며,이 방법을 사용하는 사람이 관리자가 제공 한 적절한 권한 (클레임)을 가질 수 있다는 것을 항상 확신 할 수 있습니다. 그런 다음 관리자는 누가 무엇을 할 수 있는지 결정할 수 있습니다. 개발자가 아닙니다. 비즈니스 로직이 보안 로직과 분리되는 방식입니다.
누군가 로그인 할 때마다 응용 프로그램은 해당 사용자에 대해 사용 가능한 권한을 확인하고 해당 권한 (클레임) 세트는 현재 로그인 한 사용자의 추가 속성으로 사용할 수 있습니다 (보통 클레임 세트는 로그인 한 사용자의 쿠키로 저장 됨). 데이터베이스에서 항상 권한 설정을 확인할 필요가 없습니다. 결론은 역할 기반 액세스가 아닌 클레임 기반 액세스를 적용하면 응용 프로그램에서 보안 논리를 더 잘 제어 할 수 있다는 것입니다. 실제로 역할도 클레임으로 간주 될 수 있습니다.
애플리케이션이 매우 작은 애플리케이션 인 경우 (고객 및 관리자) 고객 및 관리자이며 고객이 애플리케이션에서 의도 한 것 이외의 작업을 수행 할 가능성이없는 경우 역할 기반 액세스 제어는 목적에 부합하지만 응용 프로그램이 성장함에 따라 어느 시점에서 클레임 기반 액세스 제어의 필요성을 느끼기 시작할 것입니다.
CanCreateCustomer, CanViewAdCampaigns
나는 지금 여러 번 보안 모델을 구현했으며 이러한 개념들에 대해서도 머리를 감쌌다. 여러 번 해본 결과 여기에 이러한 개념에 대한 이해가 있습니다.
역할은 무엇인가
역할 = 사용자와 권한 의 결합 .
한편으로 역할은 권한의 모음입니다. 나는 그것을 Permission Profile이라고 부른다. 역할을 정의 할 때 기본적으로 해당 역할에 많은 권한을 추가하므로 이러한 의미에서 역할은 권한 프로파일입니다.
반면에 역할은 사용자의 모음이기도합니다. Bob과 Alice를 "관리자"역할에 추가하면 "관리자"에 그룹과 같은 두 명의 사용자 모음이 포함됩니다.
사실 역할은 사용자 모음과 권한 모음이 모두 포함되어 있다는 것입니다. 시각적으로 이것은 벤 다이어그램으로 볼 수 있습니다.
그룹이란?
그룹 = 사용자 모음
"그룹"은 엄격하게 사용자 모음입니다. 그룹과 역할의 차이점은 역할에도 권한 모음이 있지만 그룹에는 사용자 모음 만 있다는 것입니다.
허가 란 무엇인가
허가 = 과목이 할 수있는 일
권한 집합이란 무엇입니까
권한 집합 = 권한 모음
강력한 RBAC 시스템에서 권한은 사용자와 같이 그룹화 할 수도 있습니다. 그룹은 사용자 모음 인 반면 권한 집합은 권한 모음입니다. 이를 통해 관리자는 한 번에 전체 권한 모음을 역할에 추가 할 수 있습니다.
사용자, 그룹, 역할 및 권한이 결합되는 방법
강력한 RBAC 시스템에서 사용자를 역할에 개별적으로 추가하여 역할에 사용자 모음을 만들거나 그룹에 역할에 추가하여 한 번에 사용자 모음을 역할에 추가 할 수 있습니다. 어느 쪽이든 역할은 개별적으로 추가되거나 그룹을 역할에 추가하거나 사용자 및 그룹을 역할에 추가하여 사용자 모음을 가져옵니다. 권한은 같은 방식으로 생각할 수 있습니다.
역할 내에서 권한 모음을 작성하기 위해 역할에 개별적으로 권한을 추가하거나 권한 세트를 역할에 추가 할 수 있습니다. 마지막으로 권한과 권한 집합을 역할에 추가 할 수 있습니다. 어느 쪽이든 역할은 개별적으로 추가되거나 역할에 권한 집합을 추가하여 권한 모음을 가져옵니다.
역할의 전체 목적은 사용자와 권한을 결혼시키는 것입니다. 따라서 역할은 사용자 및 권한의 UNION입니다.
주장은 무엇인가
주장 = 주제가 무엇인가
클레임은 권한이 아닙니다. 이전 답변에서 지적했듯이 클레임은 주제가 "할 수있는"것이 아니라 "주인"입니다.
클레임은 역할 또는 권한을 대체하지 않으며 인증 결정을 내리는 데 사용할 수있는 추가 정보입니다.
클레임 사용시기
사용자를 역할에 추가 할 수 없거나 결정이 사용자와 권한의 연관성을 기반으로하지 않는 경우 권한 부여 결정이 필요할 때 클레임이 유용한 것으로 나타났습니다. Facebook 사용자의 예가 이것을 유발합니다. Facebook 사용자는 "역할"에 추가 된 사람이 아닐 수 있습니다. Facebook을 통해 인증 된 일부 방문자 일뿐입니다. RBAC에 잘 맞지는 않지만 인증 결정을 내리기위한 정보입니다.
@CodingSoft는 이전 답변에서 나이트 클럽 은유를 사용했습니다. 이 답변에서, 운전 면허는 일련의 청구를 포함하는 예시로 사용되었으며, 여기서 생년월일은 청구 중 하나를 나타내며 DateOfBirth 청구 값은 인증 규칙에 대해 테스트하는 데 사용됩니다. 운전 면허증을 발급 한 정부는 클레임 진정성을 제공하는 기관입니다. 따라서 나이트 클럽 시나리오에서 출입문의 경비원은 개인의 운전 면허증을보고 가짜 신분증인지 여부를 검사하여 신뢰할 수있는 기관이 발급했는지 확인합니다 (예 : 유효한 정부 발급 신분증이어야 함). 그런 다음 생년월일 (운전 면허증에 대한 많은 주장 중 하나)을보고 그 값을 사용하여 그 사람이 클럽에 입국 할 수있는 나이가되었는지 확인합니다. 그렇다면,
이제 그 기반을 염두에두고 이제 더 확장하고 싶습니다. 나이트 클럽이있는 건물에 클럽 직원 만 입장 할 수있는 사무실, 방, 부엌, 기타 층, 엘리베이터, 지하실 등이 있다고 가정합니다. 또한 특정 직원은 다른 직원이 할 수없는 특정 장소에 액세스 할 수 있습니다. 예를 들어, 관리자는 다른 직원이 액세스 할 수없는 것보다 높은 사무실 층에 액세스 할 수 있습니다. 이 경우 두 가지 역할이 있습니다. 관리자 및 직원.
공개 나이트 클럽 지역에 대한 방문자의 액세스 권한은 위에서 설명한 단일 청구로 승인되지만 직원은 다른 비공개 비공개 룸에 대한 역할 액세스 권한이 필요합니다. 그들에게는 운전 면허만으로는 충분하지 않습니다. 필요한 것은 문에 들어가기 위해 스캔하는 직원 배지입니다. 어딘가에 RBAC 시스템이있어 관리자 역할의 배지가 최상층에 액세스하고 직원 역할의 배지가 다른 회의실에 액세스 할 수 있습니다.
어떤 이유로 든 역할에 의해 특정 회의실을 추가 / 제거해야하는 경우 RBAC를 사용하여 수행 할 수 있지만 클레임에는 적합하지 않습니다.
소프트웨어의 권한
응용 프로그램에 역할을 코딩하는 것은 나쁜 생각입니다. 이것은 역할의 목적을 응용 프로그램에 하드 코딩합니다. 응용 프로그램의 특징은 기능 플래그처럼 작동하는 권한입니다. 구성을 통해 기능 플래그에 액세스 할 수있는 경우 사용자가 배치 한 모든 역할에서 수집 한 권한의 DISTINCT 컬렉션에서 파생 된 사용자 보안 컨텍스트에서 권한에 액세스 할 수 있습니다. 이것이 바로 "유효 권한"이라고합니다. 응용 프로그램은 메뉴 만 제시해야 합니다기능 / 동작에 대한 가능한 권한. RBAC 시스템은 역할을 통해 해당 권한을 사용자와 결혼하는 작업을 수행해야합니다. 이런 식으로 역할의 하드 코딩이 없으며 권한이 변경 될 때만 제거되거나 새 역할이 추가됩니다. 소프트웨어에 권한이 추가되면 절대로 변경해서는 안됩니다. 필요할 때만 (즉, 새 버전에서 기능이 중단 된 경우) 제거해야하며 새 기능 만 추가 할 수 있습니다.
마지막 메모.
그랜트 vs 거부
강력한 RBAC 시스템과 CBAC 시스템조차도 Grants와 Denials를 구분해야합니다.
역할에 권한을 추가하려면 GRANT 또는 DENY가 있어야합니다. 권한이 선택되면 모든 GRANTed 권한이 유효 권한의 사용자 목록에 추가되어야합니다. 그런 다음 모든 작업이 완료되면 DENIED 권한 목록으로 인해 시스템에서 유효 권한 목록에서 해당 권한을 제거해야합니다.
이를 통해 관리자는 주제의 최종 권한을 "조정"할 수 있습니다. 권한을 사용자에게 직접 추가 할 수있는 것이 가장 좋습니다. 이 방법으로 관리자 역할에 사용자를 추가하면 모든 것에 액세스 할 수 있지만 사용자가 남성이기 때문에 Lady 's Restroom에 대한 액세스를 거부하려고합니다. 따라서 남성 사용자를 관리자 역할에 추가하고 DENY를 사용하여 사용자 오브젝트에 권한을 추가하여 해당 레이디의 방 액세스 권한 만 제거합니다.
실제로, 이것은 클레임의 좋은 후보가 될 것입니다. 사용자에게 클레임 "성별 = 남성"이있는 경우 관리자 역할에 있으면 모든 방에 액세스 할 수 있지만 레이디 화장실에는 클레임 성별 = 여성이 필요하고 남자 화장실에는 클레임 성별 = 남성이 필요합니다. 이러한 방식으로 클레임 시행이 단일 권한 부여 규칙을 가진 모든 사람에 대해이를 처리하므로 남성 사용자에게 거부 권한을 구성 할 필요가 없습니다. 그러나 어느 쪽이든 할 수 있습니다.
요점은 권한 거부를 사용하면 예외를 구현할 수 있기 때문에 역할을보다 쉽게 관리 할 수 있다는 것입니다.
아래는 오래 전에 RBAC 모델을 보여주는 다이어그램입니다. 클레임에 대한 그래픽이 없지만 사용자가 어디에서나 사용자에게 연결된 속성이라고 상상할 수 있습니다. 또한 다이어그램에는 그룹이 표시되지 않습니다 (일부 지점에서 업데이트해야 함).
이게 도움이 되길 바란다.
2019 년 4 월 7 일 업데이트 @Brent (감사합니다)의 피드백을 바탕으로 ... 이전 답변에 대한 불필요한 참조를 제거하고 @CodingSoft에서 제공 한 "나이트 클럽"은유의 원래 기초를 설명했습니다. 다른 답변을 읽을 수 있습니다.
Emran의 답변에 전적으로 동의하지 않습니다
[Authorize(Roles="Sale")]순진하다
문제는 어떻게
[Authorize(Roles="CustomerCreator")]~와 다르다
[ClaimAuthorize(Permission="CanCreateCustomer")]둘 다 똑같이 좋다면 왜 우리는 주장이 필요한가?
나는 생각하기 때문에
위의 예에서 "CustomerCreator"는 "Asp.NETroleProvider"에서 제공 한 "role"유형의 클레임이라고 말할 수 있습니다.
청구의 추가 예.
"AAA"는 "MYExamSite.com"에서 제공하는 "MYExamSite.Score"유형의 클레임입니다.
"골드"는 "MYGYMApp"에서 제공 한 "MYGYM.Membershiptype"유형의 클레임입니다.
받아 들여진 대답은 역할을 무딘 대상으로하고 클레임을 유연한 도구로 표시하지만 그렇지 않으면 거의 동일하게 보입니다. 불행하게도,이 포지셔닝은 청구의 개념을 무시하고 근본적으로 그들의 목적에 대한 약간의 오해를 반영 할 수 있습니다.
역할은 존재하며 암시적인 범위 내에서만 의미가 있습니다. 일반적으로 응용 프로그램 또는 조직 범위입니다 (예 : Role = Administrator). 반면에 클레임은 누구나 '만들기'수 있습니다. 예를 들어 Google 인증은 사용자의 "이메일"을 포함하여 클레임을 생성하여 해당 이메일을 아이디에 첨부 할 수 있습니다. Google은 소유권 주장을하고 애플리케이션은 해당 소유권 주장을 이해하고 수락할지 여부를 선택합니다. 응용 프로그램 자체는 "Google"이라는 값으로 "authenticationmethod"(ASP.NET MVC Core Identity에서와 같이)라는 클레임을 첨부 할 수 있습니다. 각 클레임에는 범위가 포함되므로 클레임이 외부, 로컬 또는 둘 다 (또는 필요에 따라 더 세밀하게) 의미를 갖는지 식별 할 수 있습니다.
핵심 요점은 모든 클레임이 명시 적으로 ID에 첨부되고 명시 적 범위를 포함한다는 것입니다. 이러한 클레임은 물론 권한 부여에 사용될 수 있으며 ASP.NET MVC는 Authorize 특성을 통해이를 지원하지만 클레임의 유일한 목적은 아닙니다. 로컬 범위 인증에 대해 정확히 동일한 방식으로 사용할 수있는 역할과 확실히 구분되지 않습니다.
따라서 권한 부여 목적으로 역할 또는 클레임을 사용하거나 둘 다를 선택할 수 있으며 해당 역할 및 클레임이 로컬로 범위에있는 한 본질적인 장점이나 단점을 찾을 수 없습니다. 그러나 예를 들어 권한 부여가 외부 ID 주장에 의존하는 경우 역할이 부적절합니다. 외부 클레임을 수락하고이를 로컬 범위 역할로 변환해야합니다. 반드시 잘못된 점은 없지만 간접 계층을 도입하고 컨텍스트를 버립니다.
보다 광범위하게는 ABAC (Attribute-Based Access Control)를 고려해야합니다. RBAC와 ABAC는 NIST (National Institute of Standards and Technology)에서 정의한 개념입니다. 반면 CBAC는 Microsoft가 추진 한 모델로 ABAC와 매우 유사합니다.
더 많은 것을 읽으십시오 :
어떤 방법이 가장 적합한 지 결정하기 전에 먼저 인증에 필요한 것이 무엇인지 분석하는 것이 중요합니다. 아래의 Microsoft 문서에서 "주체는 청구 할 수있는 것이 아닙니다. 예를 들어, 현지 운전 면허 국에서 발급 한 운전 면허증이있을 수 있습니다. 운전 면허증에는 생년월일이 있습니다.이 경우 클레임 이름은 DateOfBirth, 클레임 값은 생년월일 (예 : 1970 년 6 월 8 일, 발급자는 운전 면허 기관)입니다. 클레임 기반 인증은 가장 간단하게 클레임의 가치를 확인하고 액세스 권한을 부여합니다. 예를 들어 나이트 클럽에 액세스하려는 경우 승인 절차는 다음과 같습니다 .6 "
이 예에서 클레임 기반 인증으로 가까운 클럽에 액세스하는 것이 나이트 클럽에서 근무하는 직원이 요구하는 인증 유형과 다른 종료됨을 알 수 있습니다.이 경우 나이트 클럽 직원은 나이트 클럽 방문자가 나이트 클럽에서 공통의 목적을 가지고 있기 때문에 나이트 클럽 방문자에게는 필요하지 않은 역할 기반 권한 부여 따라서이 상황에서는 클레임 기반 권한이 나이트 클럽 방문자에게 적합합니다.
역할 기반 권한 부여 https://docs.microsoft.com/en-us/aspnet/core/security/authorization/roles 10/14/2016 ID가 생성되면 하나 이상의 역할에 속할 수 있습니다. 예를 들어, Tracy는 관리자 및 사용자 역할에 속하는 반면 Scott은 사용자 역할에만 속할 수 있습니다. 이러한 역할을 만들고 관리하는 방법은 권한 부여 프로세스의 백업 저장소에 따라 다릅니다. ClaimsPrincipal 클래스의 IsInRole 메서드를 통해 역할이 개발자에게 노출됩니다.
클레임 기반 권한 부여 https://docs.microsoft.com/en-us/aspnet/core/security/authorization/claims 2016 년 10 월 14 일 신원이 생성되면 신뢰할 수있는 당사자가 발행 한 하나 이상의 클레임이 할당 될 수 있습니다. 클레임은 제목이 수행 할 수있는 것이 아니라 제목이 무엇인지 나타내는 이름 값 쌍입니다. 예를 들어, 지역 운전 면허 국에서 발급 한 운전 면허증이있을 수 있습니다. 운전 면허증에 생년월일이 있습니다. 이 경우 클레임 이름은 DateOfBirth이고 클레임 값은 생년월일 (예 : 1970 년 6 월 8 일)이며 발급자는 운전 면허 국이됩니다. 클레임 기반 권한 부여는 가장 간단한 방법으로 클레임 값을 확인하고 해당 값을 기반으로 리소스에 액세스 할 수 있도록합니다. 예를 들어 나이트 클럽에 액세스하려는 경우 승인 절차는 다음과 같습니다.
도어 보안 담당자는 귀하에게 생년월일 청구 가치와 그들이 발급자 (운전 면허 국)를 신뢰할 수 있는지 여부를 평가하여 액세스 권한을 부여합니다.
ID는 여러 값을 가진 여러 클레임을 포함 할 수 있으며 동일한 유형의 여러 클레임을 포함 할 수 있습니다.
클레임 방식으로 역할을 관리 할 수도 있습니다.
비즈니스 역할을 반영하는 권한 부여 역할을 작성하는 대신 CreateCustomer, EditCustomer, DeleteCustomer와 같은 조치 역할을 반영하는 역할을 작성하십시오. 필요에 따라 메소드에 주석을 답니다.
특히 역할 목록이 커질수록 개인을 일련의 작업 역할에 매핑하는 것은 간단한 일이 아닙니다. 따라서 하위 레벨 (예 : 영업, 마케팅)에서 비즈니스 역할을 관리하고 비즈니스 역할을 필요한 조치 역할에 맵핑해야합니다. 즉, 비즈니스 역할에 사용자를 추가하고 기존 권한 부여 테이블의 필수 (활동) 역할에 사용자를 맵핑합니다.
비즈니스 역할을 재정의하고 사람을 작업 역할에 직접 추가 할 수도 있습니다.
이미 작동하는 것을 기반으로하기 때문에 기존 인증 프로세스를 취소하지 않습니다. 이 방법을 구현하려면 몇 개의 테이블 만 있으면됩니다.
이 질문은 데이터베이스에서 예상되는 답변이라고 생각합니다. 이 임플란트와 관련된 테이블을 확인한 경우 다음을 찾을 수 있습니다.
이 표의 사용법은 특정 요구에 맞게 사용자 / 응용 프로그램 수명의 순간에 조정될 수 있습니다.
"구매 관리자"(PM)의 초기 단계를 고려하면 세 가지 접근 방식이 있습니다.
애플리케이션은 AspNetUserRoles를 하나의 행으로 채워서 'PM'구매 권한을 부여합니다. 금액에 관계없이 구매 주문을하려면 "PM"역할 만 있으면됩니다.
애플리케이션은 AspNetUserRoles를 하나의 행으로 채워 'PM'에 구매 권한을 부여하고 AspNetUserClaims에 TYPE '구매 금액'유형 및 "<1000"값의 청구를 채워 수량 한도를 설정합니다. 구매 주문을 발행하려면 사용자는 'PM'이 있어야하며 주문 금액은 청구 유형 '구매 금액'의 청구 값보다 작아야합니다.
응용 프로그램은 AspNetUserClaims를 TYPE '구매 금액'유형 및 "<1000"값의 청구로 채 웁니다. 이 사용자에 대한 클레임 유형 '구매 금액'의 청구 금액보다 적은 금액이 있으면 모든 사용자가 구매 주문을 발행 할 수 있습니다.
알 수 있듯이 역할 기반은 시스템 관리 관점에서 응용 프로그램 사용자의 수명을 단순화 할 수있는 엄밀한 권한을 갖습니다. 그러나 비즈니스 요구 사항 관점에서 사용자 기능을 제한합니다. 반면에 클레임 기반은 각 사용자에게 할당해야하는 매우 미세한 권리입니다. 클레임 기반은 비즈니스의 한계를 뛰어 넘지 만 시스템 관리를 매우 복잡하게 만듭니다.
RBAC (역할 기반 액세스 제어)
조직에서 다음 역할을 수행 할 수 있습니다.
종업원
매니저
HR
로그인 한 사용자가 속한 역할에 따라 응용 프로그램의 특정 리소스에 대한 액세스 권한을 부여하거나 부여하지 않을 수 있습니다. 권한 부여 확인을 위해 역할을 사용하고 있기 때문에이를 일반적으로 RBAC (역할 기반 액세스 제어) 또는 역할 기반 인증이라고합니다.
ASP.NET Core에서 역할 기반 권한 부여를 구현하기 위해 Roles 매개 변수와 함께 Authorize 특성을 사용합니다.
[Authorize(Roles = "Admin")]
public class AdministrationController : Controller
{
}클레임 기반 액세스 제어 (CBAC)
청구 란 무엇입니까? 클레임은 이름-값 쌍입니다. 실제로는 사용자가 할 수있는 것과 할 수없는 것이 아니라 사용자에 대한 정보입니다. 예를 들어 사용자 이름, 이메일, 연령, 성별 등은 모두 소유권 주장입니다. 응용 프로그램에서 권한 검사에 이러한 클레임을 사용하는 방법은 응용 프로그램 비즈니스 및 권한 요구 사항에 달려 있습니다.
예를 들어 직원 포털을 구축하는 경우 성별 클레임 값이 여성 인 경우 로그인 한 사용자가 출산 휴가를 신청할 수 있습니다. 마찬가지로 전자 상거래 응용 프로그램을 빌드중인 경우 연령 청구 값이 18 이상인 경우 로그인 한 사용자가 주문을 제출하도록 허용 할 수 있습니다.
클레임은 정책을 기반으로합니다. 정책을 만들고 해당 정책에 하나 이상의 클레임을 포함시킵니다. 그런 다음 Authorize 속성의 policy 매개 변수와 함께 정책을 사용하여 클레임 기반 권한을 구현합니다.
[Authorize(Policy = "DeleteRolePolicy")]
public async Task<IActionResult> DeleteRole(string id)
{
}