asp.net

새로운 ASP.NET Identity Core에서 클레임 메커니즘의 의미는 무엇입니까?

역할 및 클레임을 기반으로하는 두 가지 일반적인 인증 방법이 있습니다.

역할 기반 보안

사용자는 액세스 권한을 얻는 하나 이상의 역할에 할당됩니다. 또한 사용자를 역할에 할당하면 사용자는 해당 역할에 대해 정의 된 모든 액세스 권한을 즉시 얻습니다.

클레임 기반 보안

클레임 기반 ID는 클레임 ​​집합입니다. 클레임은 엔터티 (사용자 또는 다른 응용 프로그램) 자체에 대한 진술이며 단지 클레임 일뿐입니다. 예를 들어 클레임 목록에는 사용자 이름, 사용자 전자 메일, 사용자 나이, 작업에 대한 사용자 권한이있을 수 있습니다. 역할 기반 보안에서 사용자는 자격 증명을 응용 프로그램에 직접 제공합니다. 클레임 기반 모델에서 사용자는 자격 증명이 아닌 클레임을 응용 프로그램에 제공합니다. 실질적인 가치가 있다고 주장하기 위해서는, 신청이 신뢰하는 실체로부터 제기되어야합니다.

아래 단계는 클레임 ​​기반 보안 모델에서 발생하는 순서를 보여줍니다.

1. 사용자가 작업을 요청합니다. 신뢰 당사자 (RP) 응용 프로그램이 토큰을 요청합니다.
2. 사용자는 RP 응용 프로그램이 신뢰하는 발급 기관에 자격 증명을 제공합니다.
3. 발급 기관은 사용자의 자격 증명을 인증 한 후 클레임과 함께 서명 된 토큰을 발급합니다.
4. 사용자는 토큰을 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 를 방문하십시오 .

답변