ID 모델을 사용하여 클레임 및 권한 부여 관리

2025-06-17

권한 부여는 컴퓨터 리소스를 변경, 보기 또는 액세스할 수 있는 권한이 있는 엔터티를 결정하는 프로세스입니다. 예를 들어 비즈니스에서는 관리자만 직원의 파일에 액세스할 수 있습니다. WCF(Windows Communication Foundation)는 권한 부여 처리를 수행하기 위한 두 가지 메커니즘을 지원합니다. 첫 번째 메커니즘을 사용하면 기존 CLR(공용 언어 런타임) 구문을 사용하여 권한 부여를 제어할 수 있습니다. 두 번째는 ID 모델이라고 하는 클레임 기반 모델입니다. WCF는 ID 모델을 사용하여 들어오는 메시지에서 클레임을 만듭니다. ID 모델 클래스를 확장하여 사용자 지정 권한 부여 체계에 대한 새 클레임 유형을 지원할 수 있습니다. 이 항목에서는 ID 모델 기능의 주요 프로그래밍 개념과 기능에서 사용하는 가장 중요한 클래스 목록을 간략하게 설명합니다.

ID 모델 시나리오

다음 시나리오는 ID 모델 사용을 나타냅니다.

시나리오 1: ID, 역할 및 그룹 클레임 지원

사용자는 웹 서비스로 메시지를 보냅니다. 웹 서비스의 액세스 제어 요구 사항은 ID, 역할 또는 그룹을 사용합니다. 메시지 발신자는 역할 또는 그룹 집합에 매핑됩니다. 역할 또는 그룹 정보는 액세스 검사를 수행하는 데 사용됩니다.

시나리오 2: 풍부한 주장 지원

사용자는 웹 서비스로 메시지를 보냅니다. 웹 서비스의 액세스 제어 요구 사항에는 ID, 역할 또는 그룹보다 더 풍부한 모델이 필요합니다. 웹 서비스는 지정된 사용자가 풍부한 클레임 기반 모델을 사용하여 특정 보호된 리소스에 액세스할 수 있는지 여부를 결정합니다. 예를 들어 한 사용자가 다른 사용자가 액세스할 수 없는 급여 정보와 같은 특정 정보를 읽을 수 있습니다.

시나리오 3: 서로 다른 클레임 매핑

사용자가 웹 서비스에 메시지를 보냅니다. 사용자는 X.509 인증서, 사용자 이름 토큰 또는 Kerberos 토큰과 같은 다양한 방법으로 자격 증명을 지정할 수 있습니다. 웹 서비스는 사용자 자격 증명 유형에 관계없이 동일한 방식으로 액세스 제어 검사를 수행해야 합니다. 시간이 지남에 따라 추가 자격 증명 형식이 지원되는 경우 시스템은 그에 따라 진화해야 합니다.

시나리오 4: 여러 리소스에 대한 액세스 확인

웹 서비스는 여러 리소스에 액세스하려고 시도합니다. 서비스는 사용자와 연결된 클레임을 리소스에 액세스하는 데 필요한 클레임과 비교하여 지정된 사용자가 액세스할 수 있는 보호된 리소스를 결정합니다.

ID 모델 용어

다음 목록에서는 ID 모델 개념을 설명하는 데 사용되는 주요 용어를 정의합니다.

권한 부여 정책
입력 클레임 집합을 출력 클레임 집합에 매핑하기 위한 규칙 집합입니다. 권한 부여 정책을 평가하면 클레임 집합이 평가 컨텍스트에 추가되고 이후에 권한 부여 컨텍스트가 생성됩니다.

권한 부여 컨텍스트
클레임 집합 및 0개 이상의 속성 집합입니다. 하나 이상의 권한 부여 정책을 평가한 결과입니다.

클레임
클레임 유형, 권리 및 값의 조합입니다.

청구 집합
특정 발급자에서 발급한 클레임 집합입니다.

클레임 유형
일종의 클레임입니다. ID 모델 API에서 정의한 클레임은 클래스의 ClaimType 속성입니다. 시스템에서 제공하는 클레임 형식의 예는 Dns, ,Email, Hash Name, Rsa Sid, Spn System, Thumbprint Uri및 X500DistinguishedName입니다.

평가 컨텍스트
권한 부여 정책이 평가되는 컨텍스트입니다. 속성 및 클레임 집합을 포함합니다. 평가가 완료되면 권한 부여 컨텍스트의 기초가 됩니다.

신원 주장
정체성이 권리인 클레임입니다.

발급자
최소한 하나의 신원 클레임을 포함하고, 다른 클레임 집합을 발급한 것으로 여겨지는 클레임 집합입니다.

속성
평가 컨텍스트 또는 권한 부여 컨텍스트와 관련된 정보 집합입니다.

보호된 리소스
특정 요구 사항이 처음 충족되는 경우에만 사용, 액세스 또는 조작할 수 있는 시스템의 항목입니다.

오른쪽
리소스에 대한 기능입니다. ID 모델 API에서 정의한 권한은 클래스의 Rights 속성입니다. 시스템 제공 권한의 예는 다음과 Identity같습니다PossessProperty.

가치
권리가 주장되는 무언가.

클레임

ID 모델은 클레임 기반 시스템입니다. 클레임은 시스템의 일부 엔터티와 연결된 기능(종종 해당 시스템의 사용자)을 설명합니다. 지정된 엔터티와 연결된 클레임 집합을 키로 간주할 수 있습니다. 특정 클레임은 문에서 잠금을 여는 데 사용되는 물리적 키와 유사하게 해당 키의 모양을 정의합니다. 클레임은 리소스에 대한 액세스 권한을 얻는 데 사용됩니다. 지정된 보호된 리소스에 대한 액세스는 해당 리소스에 액세스하는 데 필요한 클레임과 액세스를 시도하는 엔터티와 연결된 클레임을 비교하여 결정됩니다.

청구는 특정 가치와 관련된 권리의 표현입니다. 권한은 "읽기", "쓰기" 또는 "실행"처럼 될 수 있습니다. 값은 데이터베이스, 파일, 사서함 또는 속성일 수 있습니다. 클레임에는 클레임 유형도 있습니다. 클레임 유형과 권한의 조합은 값과 관련하여 기능을 지정하는 메커니즘을 제공합니다. 예를 들어 값 "Biography.doc"에 대해 "Read" 권한이 있는 "File" 유형의 클레임은 해당 클레임이 연결된 엔터티가 파일 Biography.doc에 대한 읽기 권한을 가지고 있음을 나타냅니다. "Martin" 값에 대해 "PossessProperty" 권한이 있는 "Name" 유형의 클레임은 해당 클레임이 연결된 엔터티가 값이 "Martin"인 이름 속성을 소유하고 있음을 나타냅니다.

다양한 클레임 유형 및 권한이 ID 모델의 일부로 정의되어 있지만 시스템은 확장 가능하므로 ID 모델 인프라를 기반으로 구축된 다양한 시스템이 필요에 따라 추가 클레임 유형 및 권한을 정의할 수 있습니다.

신원 주장

한 가지 특별한 권리는 ID의 권리입니다. 이 권리를 가진 주장은 엔터티의 정체성에 대한 진술을 제시합니다. 예를 들어 "사용자 계정 이름"(UPN) 형식의 클레임이 값 someone@example.com 및 권한 Identity을 가진다면, 특정 도메인에서 특정 신원을 나타냅니다.

시스템 ID 클레임

ID 모델은 하나의 ID 클레임 System을 정의합니다. 정체성 주장은 System 엔터티가 현재 애플리케이션 또는 시스템임을 나타냅니다.

클레임 집합

ID를 나타내는 클레임 모델은 해당 엔터티가 궁극적으로 "자체"라는 개념인 경우에도 시스템의 일부 엔터티에서 항상 클레임을 발급하기 때문에 중요합니다. 클레임은 집합으로 그룹화되고 각 집합에는 발급자를 가집니다. 발급자는 클레임 집합에 불과합니다. 어떠한 재귀 관계도 결국 종료되어야 하며, 어떤 클레임 집합도 자체 발급자가 될 수 있습니다.

다음 그림은 세 가지 클레임 집합의 예를 보여 줍니다. 여기서 하나의 클레임 집합은 발급자로 다른 클레임 집합을 가지며, 이 클레임 집합은 다시 시스템 클레임 집합을 발급자로 가집니다. 따라서 클레임 집합은 임의로 깊을 수 있는 계층 구조를 형성합니다.

계층 내의 클레임 집합입니다.

여러 클레임 집합이 동일한 발급 클레임 집합을 가질 수 있으며, 이는 다음 그림으로 설명됩니다.

동일한 발급 클레임 집합에서 유래된 여러 클레임 집합.

자체 발급자인 클레임 집합을 제외하고 ID 모델은 루프를 형성하는 클레임 집합에 대한 지원을 제공하지 않습니다. 따라서 클레임 집합 B가 클레임 집합 A에 의해 발급되고, 다시 클레임 집합 A가 클레임 집합 B에 의해 발급되는 상황은 결코 발생할 수 없습니다. 또한 ID 모델은 여러 발급자가 있는 클레임 집합에 대한 지원을 제공하지 않습니다. 두 개 이상의 발급자가 지정된 클레임 집합을 발급해야 하는 경우 각각 동일한 클레임을 포함하지만 발급자가 다른 여러 클레임 집합을 사용해야 합니다.

클레임의 원본

클레임은 다양한 소스에서 올 수 있습니다. 클레임의 일반적인 소스 중 하나는 사용자가 제공하는 자격 증명입니다(예: 웹 서비스로 전송된 메시지의 일부로). 시스템은 이러한 클레임의 유효성을 검사하고 사용자와 연결된 클레임 집합의 일부가 됩니다. 다른 시스템 구성 요소는 운영 체제, 네트워크 스택, 런타임 환경 또는 애플리케이션을 포함하지만 이에 국한되지 않는 클레임의 원본일 수도 있습니다. 또한 원격 서비스는 클레임의 원본일 수도 있습니다.

권한 부여 정책

ID 모델에서 클레임은 권한 부여 정책을 평가하는 프로세스의 일부로 생성됩니다. 권한 부여 정책은 기존 클레임 집합(비어 있을 수 있음)을 검사하고 이미 있는 클레임 및 추가 정보를 기반으로 추가 클레임을 추가하도록 선택할 수 있습니다. 이는 클레임 간의 매핑의 기초를 제공합니다. 시스템에 클레임이 있거나 없는 경우 추가 클레임을 추가하는지 여부와 관련하여 권한 부여 정책의 동작에 영향을 줍니다.

예를 들어 권한 부여 정책은 시스템을 사용하는 다양한 엔터티의 생년월일을 포함하는 데이터베이스에 액세스할 수 있습니다. 권한 부여 정책은 해당 정보를 사용하여 컨텍스트에 "Over18" 클레임을 추가합니다. 이 Over18 클레임은 18 세 이상이라는 사실 이외의 엔터티에 대한 정보를 공개하지 않습니다. 'Over18' 클레임의 해석은 해당 클레임의 의미 체계를 이해하는 데 달려 있습니다. 클레임을 추가한 권한 부여 정책은 이러한 의미 체계를 어느 정도 이해합니다. 이후에 정책 평가에서 발생하는 클레임을 검사하는 코드도 해당 의미 체계에 대해 알 수 있습니다.

지정된 권한 부여 정책은 다른 권한 부여 정책이 클레임을 추가할 때 권한 부여 정책이 더 많은 클레임을 추가할 수 있으므로 여러 번 평가해야 할 수 있습니다. ID 모델은 강제로 적용되는 권한 부여 정책에 의해 컨텍스트에 더 이상 클레임이 추가되지 않을 때까지 평가를 계속하도록 설계되었습니다. 이러한 권한 부여 정책의 지속적인 평가는 권한 부여 정책과 관련하여 특정 평가 순서를 적용하는 요구 사항을 방지합니다. 어떤 순서로든 평가할 수 있습니다. 예를 들어 정책 A가 클레임 B를 추가한 경우 정책 X가 클레임 Z만 추가하는 경우 X가 먼저 평가되면 처음에는 클레임 Z를 추가하지 않습니다. 그런 다음 A가 평가되고 클레임 B를 추가합니다. X는 두 번째로 평가되고 이번에는 클레임 Z를 추가합니다.

지정된 시스템에는 많은 권한 부여 정책이 적용될 수 있습니다.

Key-Making 기계

연결된 권한 부여 정책 그룹을 평가하는 것은 키를 만드는 컴퓨터를 사용하는 것과 같습니다. 권한 부여 정책은 각각 평가되고 클레임 집합이 생성되어 키의 모양을 구축합니다. 키의 모양이 완료되면 일부 잠금을 여는 데 사용할 수 있습니다. 키의 모양은 권한 부여 관리자가 만든 "권한 부여 컨텍스트"에 저장됩니다.

권한 부여 컨텍스트

권한 부여 관리자는 설명된 대로 다양한 권한 부여 정책을 평가하며, 그 결과는 권한 부여 컨텍스트(클레임 집합 및 일부 관련 속성)입니다. 권한 부여 컨텍스트를 검사하여 해당 컨텍스트에 있는 클레임, 이러한 다양한 클레임 간의 관계(예: 발급 클레임 집합) 및 궁극적으로 리소스에 액세스하기 위해 충족해야 하는 일부 요구 사항과 비교할 수 있습니다.

잠금장치

권한 부여 컨텍스트(클레임 집합)가 키인 경우 보호된 특정 리소스에 대한 액세스 권한을 부여하기 위해 충족해야 하는 요구 사항은 키가 적합해야 하는 잠금을 구성합니다. ID 모델은 이러한 요구 사항이 표현되는 방식을 공식화하지 않지만 시스템의 클레임 기반 특성을 고려할 때 권한 부여 컨텍스트의 클레임을 일부 필수 클레임 집합과 비교하는 작업이 포함됩니다.

요약

ID 모델은 클레임의 개념을 기반으로 합니다. 클레임은 집합으로 그룹화되고 권한 부여 컨텍스트에서 집계됩니다. 권한 부여 컨텍스트는 클레임 집합을 포함하며 권한 부여 관리자와 연결된 하나 이상의 권한 부여 정책을 평가한 결과입니다. 이러한 클레임 집합을 검사하여 액세스 요구 사항이 충족되었는지 확인할 수 있습니다. 다음 그림에서는 이러한 다양한 ID 모델 개념 간의 관계를 보여 줍니다.

클레임 및 권한 부여 관리

WCF 및 ID 모델

WCF는 권한 부여를 수행하기 위한 기준으로 ID 모델 인프라를 사용합니다. WCF에서 클래스를 ServiceAuthorizationBehavior 사용하면 권한 부여 정책을 서비스의 일부로 지정할 수 있습니다. 이러한 권한 부여 정책을 외부 권한 부여 정책이라고 하며 로컬 정책에 따라 또는 원격 서비스와의 상호 작용을 통해 클레임 처리를 수행할 수 있습니다. 클래스가 ServiceAuthorizationManager 나타내는 권한 부여 관리자는 다양한 자격 증명 유형(토큰)을 인식하고 들어오는 메시지에 적합한 클레임으로 권한 부여 컨텍스트를 채우는 권한 부여 정책과 함께 외부 권한 부여 정책을 평가합니다. 권한 부여 컨텍스트는 클래스로 AuthorizationContext 표시됩니다.

ID 모델 프로그래밍

다음 표에서는 ID 모델 확장을 프로그래밍하는 데 사용되는 개체 모델에 대해 설명합니다. 이러한 클래스는 모두 System.IdentityModel.Policy 또는 System.IdentityModel.Claims 네임스페이스에 있습니다.

클래스	설명
권한 부여 구성 요소	인터페이스를 구현하는 ID 모델 클래스입니다 IAuthorizationComponent .
IAuthorizationComponent	단일 읽기 전용 문자열 속성인 ID를 제공하는 인터페이스입니다. 이 속성의 값은 이 인터페이스를 구현하는 시스템의 각 인스턴스에 대해 고유합니다.
AuthorizationContext	속성이 0개 이상인 인스턴스 집합 을 포함하는 `ClaimSet`입니다. 하나 이상의 권한 부여 정책을 평가한 결과입니다.
Claim	클레임 유형, 권리 및 값의 조합입니다. 오른쪽 부분과 값 부분은 청구 유형에 의해 제한됩니다.
ClaimSet	추상 기본 클래스입니다. 인스턴스의 `Claim` 컬렉션입니다.
DefaultClaimSet	봉인된 클래스입니다. 클래스의 구현입니다 `ClaimSet` .
EvaluationContext	추상 기본 클래스입니다. 정책 평가 중에 권한 부여 정책에 전달됩니다.
IAuthorizationPolicy	권한 부여 정책 클래스에 의해 구현되고 `IAuthorizationComponent`에서 파생된 인터페이스입니다.
Rights	미리 정의된 오른쪽 값을 포함하는 정적 클래스입니다.

다음 클래스는 아이덴티티 모델 프로그래밍에도 사용되지만 System.IdentityModel.Policy 또는 System.IdentityModel.Claims 네임스페이스에서는 찾을 수 없습니다.

클래스	설명
ServiceAuthorizationManager	서비스의 각 작업에 대해 클레임 기반 권한 부여 검사를 수행하는 메서드 CheckAccessCore를 제공하는 클래스입니다. 클래스에서 파생하고 메서드를 재정의해야 합니다.
ServiceAuthorizationBehavior	권한 부여와 관련된 서비스의 동작과 관련된 다양한 속성을 제공하는 봉인된 클래스입니다.
ServiceSecurityContext	권한 부여 컨텍스트를 포함하여 현재 실행 중이거나 실행될 작업에 대한 보안 컨텍스트를 제공하는 클래스입니다. 이 클래스의 인스턴스는 .의 OperationContext일부입니다.

중요 멤버

다음 멤버는 일반적으로 새 클레임 형식을 만드는 데 사용됩니다.

회원	설명
CheckAccessCore	파생 클래스는 서비스에서 작업을 실행하기 전에 클레임 기반 액세스 검사를 수행하기 위해 이 메서드를 구현합니다. 제공된 OperationContext정보 또는 다른 위치의 모든 정보는 액세스 확인 결정을 내릴 때 검사할 수 있습니다. CheckAccessCore 반환`true`되는 경우, 액세스 권한이 부여되고 작업을 실행할 수 있습니다. `CheckAccessCore`가 `false`를 반환하면, 액세스가 거부되어 작업이 실행되지 않습니다. 예를 들어 방법 : 서비스에 대한 사용자 지정 권한 부여 관리자 만들기를 참조하세요.
ServiceAuthorizationManager	ServiceAuthorizationManager 서비스에 대한 값을 반환합니다. ServiceAuthorizationManager는 권한 부여 결정을 내릴 책임이 있습니다.
ExternalAuthorizationPolicies	서비스에 대해 지정된 사용자 지정 권한 부여 정책의 컬렉션입니다. 이러한 정책은 들어오는 메시지의 자격 증명과 연결된 정책 외에 평가됩니다.