새로운 ASP.NET Identity Core에서 클레임 메커니즘의 의미를 설명해 줄 수 있습니까?
내가 볼 수 있듯이, 거기에있다 AspNetUserLogins가 들어 테이블 UserId, LoginProvider및 ProviderKey.
그러나 데이터가 AspNetUserClaims테이블에 추가되는 시점 과이 테이블이 어떤 상황에 사용되는지 에 대한 정보를 여전히 이해하거나 찾을 수 없습니다 .
답변
새로운 ASP.NET Identity Core에서 클레임 메커니즘의 의미는 무엇입니까?
역할 및 클레임을 기반으로하는 두 가지 일반적인 인증 방법이 있습니다.
역할 기반 보안
사용자는 액세스 권한을 얻는 하나 이상의 역할에 할당됩니다. 또한 사용자를 역할에 할당하면 사용자는 해당 역할에 대해 정의 된 모든 액세스 권한을 즉시 얻습니다.
클레임 기반 보안
클레임 기반 ID는 클레임 집합입니다. 클레임은 엔터티 (사용자 또는 다른 응용 프로그램) 자체에 대한 진술이며 단지 클레임 일뿐입니다. 예를 들어 클레임 목록에는 사용자 이름, 사용자 전자 메일, 사용자 나이, 작업에 대한 사용자 권한이있을 수 있습니다. 역할 기반 보안에서 사용자는 자격 증명을 응용 프로그램에 직접 제공합니다. 클레임 기반 모델에서 사용자는 자격 증명이 아닌 클레임을 응용 프로그램에 제공합니다. 실질적인 가치가 있다고 주장하기 위해서는, 신청이 신뢰하는 실체로부터 제기되어야합니다.
아래 단계는 클레임 기반 보안 모델에서 발생하는 순서를 보여줍니다.
- 사용자가 작업을 요청합니다. 신뢰 당사자 (RP) 응용 프로그램이 토큰을 요청합니다.
- 사용자는 RP 응용 프로그램이 신뢰하는 발급 기관에 자격 증명을 제공합니다.
- 발급 기관은 사용자의 자격 증명을 인증 한 후 클레임과 함께 서명 된 토큰을 발급합니다.
- 사용자는 토큰을 RP 애플리케이션에 제공합니다. 응용 프로그램은 토큰 서명의 유효성을 검사하고 클레임을 추출하며 클레임을 기반으로 요청을 수락하거나 거부합니다.
그러나 데이터가 AspNetUserClaims에 추가 되고이 테이블이 어떤 상황에 처해 있는지 여전히 이해하고 정보를 찾을 수 없습니다.
역할 기반 보안이 사용되지 않고 클레임 기반 보안을 사용하기로 선택한 경우 AspNetUserClaims 테이블을 사용해야합니다. ASP.NET ID에서 클레임을 사용하는 방법에 대한 자세한 내용은 아래 링크를 참조하십시오.
http://kevin-junghans.blogspot.com/2013/12/using-claims-in-aspnet-identity.html
최신 정보
역할 기반 보안을 사용해야하는 시간과 클레임 기반은 언제입니까? 몇 가지 예를 들어 주시겠습니까?
역할 기반 또는 클레임 기반 보안을 사용하거나 사용하지 않을 명확한 상황은 없습니다. B 대신 A를 사용하는 경우와는 다릅니다.
그러나 클레임 기반 액세스 제어는 핵심 비즈니스 로직에서 권한 부여 규칙을 더 잘 분리 할 수있게합니다. 권한 부여 규칙이 변경 되더라도 핵심 비즈니스 로직은 영향을받지 않습니다. 클레임 기반 접근 방식을 선호하는 상황이 있습니다.
때로는 청구가 필요하지 않습니다. 이것은 중요한 면책 조항입니다. 내부 응용 프로그램이 많은 회사는 Windows 통합 인증을 사용하여 클레임에서 제공하는 많은 이점을 얻을 수 있습니다. Active Directory는 사용자 ID를 저장하는 데 큰 도움이되며 Kerberos는 Windows의 일부이므로 응용 프로그램에 많은 인증 논리를 포함 할 필요가 없습니다. 빌드 한 모든 응용 프로그램이 Windows 통합 인증을 사용할 수있는 한 이미 신원 유토피아에 도달했을 수 있습니다. 그러나 Windows 인증 이외의 다른 것이 필요한 여러 가지 이유가 있습니다. Windows 도메인에 계정이없는 사람들이 사용하는 웹 응용 프로그램이있을 수 있습니다. 또 다른 이유는 회사가 다른 회사와 합병하여 트러스트 관계가없는 두 개의 Windows 포리스트에서 인증하는 데 문제가 있습니다. .NET Framework가 아닌 응용 프로그램이있는 다른 회사와 ID를 공유하거나 다른 플랫폼 (예 : Macintosh)에서 실행되는 응용 프로그램간에 ID를 공유해야 할 수 있습니다. 여기에는 클레임 기반 ID가 올바른 선택 일 수있는 몇 가지 상황이 있습니다.
자세한 내용은 http://msdn.microsoft.com/en-us/library/ff359101.aspx 를 방문하십시오 .
답변
@Lin이 위에서 말한 것에 더 추가하십시오. 나는 구체적으로 질문을 언급하고 있습니다 :
역할 기반 보안을 사용해야하는 시간과 클레임 기반은 언제입니까? 몇 가지 예를 들어 주시겠습니까?
기술자와 관리자가있는 시계 시스템이있는 경우를 고려하십시오. 매주 말에 기술자는 해당 주에 근무한 장인의 근무 시간을 보여주는 시계 정보와 보고서를 정리해야합니다. 이러한 시스템은 최종 보고서를 제출하기 전에 수정하거나 수정해야하는 경우가 있습니다. 직원에게 과다 지불 또는 과소 지불을 원하지 않기 때문입니다. 하거나 사용Role-Based 하여 Manager 및 Technician에 대한 접근 방식을 사용할 수 있습니다Manager RoleTechnician Role . 그러나 Manager Role장인의 시계 정보에 액세스하고 편집 할 수있는 능력을 가진 사람입니다. 반면에Technician Role이러한 정보 없이는 이러한 정보에 액세스 할 수 없습니다. 그러나 여기 흥미로운 부분이 있습니다. 관리자는 청구를하고 기술자가 시계 시스템에 액세스하여 보고서를 작성할 수 있습니다. 따라서 편집없이 액세스 할 수만 주장하거나 액세스 및 편집 기능을 사용하여 주장 할 수 있습니다.
기본적으로 관리자로서 기술자가 액세스 할 수없는 일부 정보에 액세스 할 수 있습니다. 그러나 나는 항상 사무실 주위에 있지는 않습니까? 내가 없을 때에도 여전히 일을 할 수 있도록 어떻게해야합니까? 이를 해결하기 위해 시스템은 관리자가 특정 정보에 액세스하지 않고도 사람들에 대한 클레임을 만들 수있는 기능을 가질 수 있습니다. 우리는 종종 ERP 시스템의 모든 곳에서 이것을 볼 수 있습니다. 일부 모듈에 액세스 할 수없는 사용자가 승격되면 ERP 시스템의 더 많은 모듈에 권한을 부여하고 때로는 동일한 사용자 역할을 유지합니다.
이것은 주장과 역할을 더 이해하기 위해 고려할 수있는 예입니다.
답변
ASP.Net ID에는 두 가지 유형의 인증이 있습니다.
- 역할 기반
- 클레임 기반
둘 중 하나를 사용하거나 동시에 사용할 수 있습니다. 매우 정의 된 사항을 기반으로 역할을 사용하십시오. 예를 들어 두 역할과 교사를 만듭니다. 교사 만 과목을 추가 할 수 있습니다. 따라서 과목을 추가 할 수있는 사용자에게 교사 역할을 할당했습니다.
클레임 기반이 더 유연합니다. 일부 학생들이 과목을 추가 할 수있는 요건이 있다고 가정합니다. 이 경우 학생이되고 과목을 추가 할 수있는 역할을 하나 더 만들어야합니다. 그러나 클레임 기반을 사용하는 경우 매우 쉽습니다. addSubject와 같은 클레임을 생성하고 사용자를 추가하여 액세스 권한을 부여하려는 사용자에게 할당하십시오.
