클레임으로 어떤 데이터를 저장해야합니까?

ASP.Net Core에서 Claims권한 부여가 매우 정확 하지 않은 방법 이라는 것을 알았습니다 . 우리는 무엇이든 추가 ClaimType하고 ClaimValue짝을 지을 수 있습니다 . 그룹, 이름, 성, brithdate, canAccessThisURI, isEditor 등입니다. 그러나이 방법 (클레임으로 저장할 수있는 모든 것을 저장)은 내 응용 프로그램 데이터의 50 %를 포함하는 거대한 클레임 테이블을 만듭니다.

모범 사례로서 클레임으로 저장해야 할 공통 데이터가 무엇인지 궁금합니다.

주장은 단순히 시스템에서 누군가 를 식별 하거나 권한을 부여 하는 데 사용될 수있는 사용자에 대한 사실 입니다. 이 두 가지 제약 조건은 주장으로하는 것을 제한하기에 충분해야합니다.

클레임에 대한 몇 가지 아이디어는 다음과 같습니다.

• 사용자 아이디
• 사용자 이름
• 사용자 이메일
• 역할
• 그룹 멤버십

사용자의 메타 데이터는 사용자를 위해 앱을 개인화하고 사용자를 데이터와 연결하는 데 필요한 것으로 제한되어야합니다. 사용자의 ID는 사용자를 데이터와 연관 시키거나 감사 추적을 제공하기에 충분합니다. 욕심하지 마십시오.

역할 및 그룹 멤버십은 권한 주장입니다. 예를 들어 응용 프로그램에 그룹이있는 경우 사용자가 속한 그룹 목록을 통해 개인 그룹에 액세스 할 수 있는지 여부를 빠르게 확인할 수 있습니다. 역할은 좀 더 세분화되어 있으며 사용자가 가진 권한에 대해 이야기합니다. 이들은 일반적으로 응용 프로그램에 따라 다르므로 적용 할 항목 만 추가하십시오.

이러한 방식으로 수행하는 많은 시스템, 특히 STS / 페더레이션 시스템이 있습니다.

• 사용자를 고유하게 설명하는 하나의 주장
• 그들이 (그리고 다른 사람들이) 접근 할 수있는 일반적인 개념적 것들을 설명하는 주장의 구색

앱 내 사용자의 "프로필"데이터는 사용중인 인증 소스로 /로부터 변환되지 않을 수 있으며 항상 또는 모든 사용자에게 동일한 엔드 포인트를 사용할 수는 없습니다.

이전 양식 인증에 익숙한 경우 사용자 이름 및 역할 모델과 유사하며 System.Security.Claims.ClaimTypes 이름 및 역할 유형을 적절하게 사용하는 경우에도 많은 기본 제공 항목이 여전히 보입니다.

이전 모델이나 새 모델 모두 클레임 또는 역할 상속에 대해 많은 것을 제공하지는 않았지만 구현 및 구현이 특히 어렵지 않으므로 요청에서 계속 유지 해야하는 클레임 ​​또는 역할의 양을 줄일 수 있습니다. 요청합니다.

애플리케이션에서 생일을 추적해야하지만 보안 메커니즘에서 생일을 사용할 필요가없는 경우에는 클레임 ​​콜렉션에 생일을 유지하는 데 아무런 이점이 없습니다. 별도의 프로파일 데이터 세트 또는 무언가에 넣으십시오.

애플리케이션이 다른 시스템에서 청구로 생일을 가져와야하는 경우 federatedAuthentication을 사용자 정의하거나 추가 청구가 지속되도록하는 것과 같은 것을 찾고 있습니다.