RFC 7643 한글 해설 1 - 용어 및 스키마 설명

이 문서는 RFC 7643을 이해하기 쉽도록 한글로 재작성한 것입니다. 한글 표현에 대한 다양한 의견 환영합니다.

들어가며

SCIM이란?

SCIM의 목적은 효율적인 프로비저닝이다. SCIM의 효용은 범용적인 프로비저닝 앱을 손쉽게 개발할 수 있다는 것인데, 실제로 각 IdP 및 SP 서비스를 살펴 보면 몇 가지 설정만으로 “프로비저닝 앱”을 제작할 수 있는 플랫폼이 제공된다.(예: Microsoft Entra ID, Okta 등)

이를 위해 각 IdP 및 SP 서비스는 SCIM 표준 스키마를 따르는 사용자 및 그룹 데이터베이스를 가정하여, 표준 프로토콜을 따르는 SCIM API를 사용하여 프로비저닝을 수행할 수 있도록 준비하기만 하면 된다.

 

 

이 문서는 RFC 7643 - System for Cross-domain Identity Management: Core Schema(2015-09)의 섹션 2~7을 한글로 번역하고 해설을 덧붙인 자료이다. 영어 원문이 궁금한 사람은 공식 홈페이지(링크) 문서를 참고하기 바란다.

---

 

1. 용어 정의

• SP; Service Provider: SCIM 프로토콜을 통해 신원 정보를 제공하는 HTTP 웹 애플리케이션
• Client: SP가 유지 관리하는 신원 데이터를 관리하기 위해 SCIM 프로토콜을 사용하는 웹사이트 또는 애플리케이션
  - 클라이언트는 대상 SP에게 SCIM HTTP 요청을 시작함)
• Provisioning Domain: 법적 또는 기술적 이유로 SP의 도메인 외부에 있는 관리 도메인
  - 예: 기업 내의 SCIM 클라이언트(프로비저닝 클라이언트)는 다른 법적 실체가 소유하거나 제어하는 SCIM SP와 통신함
• Resource Type: SP가 관리하는 리소스의 유형
  - 리소스 이름, 엔드포인트 URL, 스키마, 리소스가 관리되고 구성되는 방식을 나타내는 기타 메타데이터
  - 예: "User" 또는 "Group"
• Resource: SP가 관리하며 하나 이상의 속성을 포함하는 아티팩트
  - 예: "User" 또는 "Group"
• Endpoint: SP의 기본 URI([RFC7644]의 1.3절 참조)에 대해 상대적으로 정의된 기본 경로
  - SCIM 리소스에 대해 SCIM 작업을 수행할 수 있음
  - 예시: SP의 기본 URI가 "https://example.com/"인 경우, "User" 리소스는 "https://example.com/Users" 또는 "https://example.com/v2/Users" 엔드포인트에서 접근할 수 있음(v2와 같은 프로토콜 버전 관리는 [RFC7644]의 3.13절 참조)
  - SP 스키마는 "/Schemas" 엔드포인트에서 반환될 수 있음(MAY)
• Schema: 전체 또는 부분 리소스의 내용을 설명하는 속성 정의의 집합
  - 예: "urn:ietf:params:scim:schemas:core:2.0:User"
  - 속성 정의: 속성 이름, 타입(예: 문자열, 바이너리), 카디널리티(단일, 다중, 복합), 변경 가능성, 반환 가능성 등 메타데이터
• Singular Attribute: 0..1 값이 포함된 리소스 속성
  - 예: "displayName"
• Multi-valued Attribute: 0..n 값이 포함된 리소스 속성
  - 예: "emails"
• Simple Attritube: 값이 기본형인 단일 또는 다중 값 속성
  - 예: "String"
  - 단순 속성은 하위 속성을 포함할 수 없음(MUST NOT)
• Complex Attribute: 하나 이상의 단순 속성으로 구성된 값이 있는 단일 또는 다중 값 속성
  - 예: "addresses"는 "streetAddress", "locality", "postalCode", "country"와 같은 하위 속성을 가짐
• Sub-Attribute: 복합 속성(Complex Attribute) 내에 포함된 단순 속성

 

2. 스키마

SCIM 서버는 리소스 집합(set)을 제공한다. 리소스 집합은 스키마 URI 집합과 리소스 유형으로 정의된 내용만 허용된다. SCIM 스키마는 [XML-Schema]와 달리, 문서 중심(document-centric)이 아니다. SCIM 스키마는 속성 기반(attribute based)으로 지원된다. 각 속성은 다른 유형, 변경 가능성(mutability), 카디널리티(cardinality) 또는 반환 가능성(returnability)을 가질 수 있다.

문서 및 메시지 유효성 검사는 SCIM 사양에 명시된 대로, 수신자 측에서 수행한다. 유효성 검사는 SCIM 프로토콜 요청([RFC7644] 참조)의 맥락에서 수신자에 의해 수행된다. 예를 들어, SCIM 서비스 제공자가 기존 리소스를 교체하라는 요청을 JSON 객체로 받으면, 관련 스키마에서 정의된 특성을 고려하여, 각 속성을 교체하거나 무시할 지 여부를 결정한다.(예: 변경 가능성)

이 문서는 사용자 및 그룹 리소스에 대한 최소한의 핵심 스키마(minimal core schema)를 제공한다. 여러 기존 배포 및 스키마에 존재하는 공통 속성을 포괄한다. 또한 이 문서는 서비스 제공자가 특정 케이스에서 새로운 리소스와 속성을 추가 정의할 수 있도록, 스키마 확장을 위한 표준 방법을 명시한다.

리소스는 "User" 또는 "Group"과 같은 공통 리소스 유형으로 분류된다. 같은 유형의 리소스를 모은 것(collection)은 보통 같은 "컨테이너"("폴더") 엔드포인트에 포함된다.

 

 

2.1. 속성

리소스는 한 개 이상의 스키마로 식별되는 속성 모음이다. 속성은 속성 이름과 최소 한 개의 값 또는 복합 값(한 개의 값 또는 복합 값 모두, 다중 값일 수 있음)으로 이루어진다. SCIM 스키마는 각 속성에 대해, 데이터 유형, 복수성(plurality), 변경 가능성, 기타 속성과 구별되는 특징을 정의한다.

속성 이름은 대소문자 무관(case insensitive)하며, 종종 "카멜케이스"(e.g., "camelCase")로 표현된다. SCIM 리소스는 JSON [RFC7159] 형식으로 표현되며, 3절에 따라 "schemas" 속성을 통해 스키마를 명시해야 한다.(MUST)

속성 이름에 대한 ABNF 규칙:

• ATTRNAME = ALPHA *(nameChar)
• nameChar = "$" / "-" / "_" / DIGIT / ALPHA

이 문서는 ABNF의 "Core Rules"를 사용한다; [RFC5234]의 부록 B 참조. 달리 명시하지 않는 한, 모든 ABNF 문자열은 대소문자를 구분하지 않으며 이 문자열의 문자 집합은 US-ASCII이다. 예를 들어, 위 규칙에 의해 정의된 모든 속성 이름은 대소문자를 구분하지 않는다.

속성 이름을 정의할 때, 하이픈("-")은 자바스크립트 속성 이름(또는 일부 다른 언어의 속성 이름)에서 허용되지 않음에 유의해야 한다. HTTP 프로토콜과 JSON 표기법 내에서 알려진 문제는 없지만, 하이픈을 포함하는 속성 이름은 자바스크립트 속성의 해당 이름을 선언할 때 이스케이프해야 할 수 있다.

 

2.2. 속성 특성

모든 속성은 서비스 제공자가 다루고자 하는 처리 방식과 속성 유형을 설명하는 일련의 특성 집합(set)을 가진다. 전체 정의는 7절에서 찾을 수 있다. 특성 집합에는 다음이 포함된다:

• "required"
• "canonicalValues"
• "caseExact"
• "mutability"
• "returned"
• "uniqueness"
• "referenceTypes"

7절에서 달리 명시하지 않는 한, SCIM 속성은 다음과 같은 특성을 가진다:

• "required": "false"(즉, 필수 아님)
• "canonicalValues": 할당된 값 없음(예: 2.4절에서 설명된 "type" 하위 속성)
• "caseExact": "false"(즉, 대소문자를 구분하지 않음)
• "mutability": "readWrite"(즉, 수정 가능)
• "returned": "default"(기본적으로 속성 값이 반환됨)
• "uniqueness": "none"(고유성이 강제되지 않음)
• "type": "string"(2.3.1절)

 

2.3. 속성 데이터 유형

속성 데이터 유형은 JSON [RFC7159]에서 파생되었다. JSON 형식은 제한된 데이터 유형 집합을 정의한다. 따라서, 적절한 경우 XML 스키마 [XML-Schema]에서 파생된 대체 JSON 표현이 아래에 정의된다. SCIM 확장은 새로운 데이터 유형을 도입할 수 없다.(SHOULD NOT)

• String: UTF-8로 인코딩된 0개 이상의 유니코드 문자열, [RFC2277] 및 [RFC3629]를 따름
  • JSON 형식은 [RFC7159]의 7절에 정의됨
  • SCIM 스키마 유형이 "string"인 속성은 필요한 데이터 형식을 지정할 수 있음(MAY)
  • 또한, "canonicalValues"가 지정된 경우, 서비스 제공자는 수락할 수 있는 값을 지정하여 제한할 수 있음(MAY)
• Boolean: "true" 또는 "false"
  • JSON 형식은 [RFC7159]의 3절에 정의됨
  • 불리언은 대소문자 구분이나 고유성이 없음
• Decimal: 소수점 양쪽에 최소 하나의 숫자가 있는 실수
  • JSON 형식은 [RFC7159]의 6절에 정의됨
  • 소수점은 대소문자 구분이 없음
• Integer: 분수나 소수점이 없는 숫자 그 자체
  • JSON 형식은 [RFC7159]의 6절에 정의됨
  • 값에 분수나 지수 부분이 포함되어서는 안 된다는 추가 제약이 있음(MUST NOT)
  • 정수는 대소문자 구분이 없음
• DateTime: 날짜 시간 값(예: 2008-01-23T04:56:22Z)
  • 속성 값은 [XML-Schema]의 3.3.7절에 명시된 유효한 xsd:dateTime으로 인코딩되어야 함(MUST)
  • 날짜와 시간을 모두 포함해야 함(MUST)
  • 날짜 시간 형식은 대소문자 구분이나 고유성이 없음
  • JSON 형식으로 표현된 값은 위의 XML 제약사항을 준수해야 함(MUST)
  • [RFC7159]의 7절에 따라 JSON 문자열로 표현됨
• Binary: 임의의 이진 데이터
  • 속성 값은 [RFC4648]의 4절에 명시된 대로 base64로 인코딩되어야 함(MUST)
  • URL-safe 인코딩이 필요한 경우, 속성 정의는 [RFC4648]의 5절에 따라 base64 URL 인코딩이 사용되도록 지정할 수 있음(MAY)
  • 속성 정의에서 달리 명시하지 않는 한, 끝 패딩 문자("=")는 생략될 수 음(MAY)
  • JSON 표현에서 인코딩된 값은 [RFC7159]의 7절에 따라 JSON 문자열로 표현됨
  • 이진은 대소문자 구분이 있으며 고유성이 없음
• Reference: 리소스에 대한 URI
  • 리소스는 SCIM 리소스이거나, 리소스에 대한 외부 링크(예: 사진)이거나, URN과 같은 식별자일 수 있음(MAY)
  • 리소스 값은 타겟 리소스의 절대(absolute) 또는 상대(relative) URI여야 함(MUST)
  • 상대 URI는 [RFC3986]의 5.2절에 명시된 대로 해석되어야 하나, 상대 URI 해석을 위한 기본 URI는, 엔드포인트 URI(SCIM 서비스 제공자 루트 엔드포인트)를 제외한 모든 URI 구성 요소와 경로 세그먼트를 포함해야 함(MUST)
    • 예를 들어, "https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646"
    • 기본 URI: "https://example.com/v2/"
    • 상대 URI: "Users/2819c223-7f76-453a-919d-413861904646"
  • JSON 표현에서 URI 값은 [RFC7159]의 7절에 따라 JSON 문자열로 표현됨
  • 참조는 대소문자를 구분함
  • 참조는 이 문서의 7절에 따라 어떤 유형의 리소스가 연결될 수 있는지를 나타내는 "referenceTypes" 속성을 가짐
  • 참조 URI는 HTTP로 접근 가능한 리소스여야 함(MUST)
  • 참조 URI에 대한 GET 작업을 수행하는 HTTP 클라이언트는 대상 리소스 또는 적절한 HTTP 응답 코드를 받아야 함(MUST)
  • SCIM 서비스 제공자는 SCIM 리소스를 참조하는 참조 유형에 대해 참조 무결성을 강제할 수 있음(MAY)
  • 관례적으로, 참조는 복합 또는 다중 값 속성에서 "$ref" 하위 속성으로 일반적으로 표현됨(OPTIONAL)
• Complex: 하나 이상의 단순 속성으로 구성된 값이 있는 단일 또는 다중 값 속성
  • JSON 형식은 [RFC7159]의 4절에 정의되어 있음
  • 구성 요소 속성의 순서는 중요하지 않음
  • 서버와 클라이언트는 객체가 생성되거나 분석될 때 속성이 특정 순서를 가지도록 요구하거나 기대해서는 안 됨(MUST NOT)
  • 복합 속성은 고유성이나 대소문자 구분이 없음
  • 복합 속성은 하위 속성을 보유한 하위 속성을 가지지 않아야 함(MUST NOT)

 

2.4. 다중 값 속성

다중 값 속성은 배열 형식으로 정의된 요소 목록으로 구성된다. (배열 형식은 [RFC7159]의 5절에 정의됨) 요소는 다음 중 하나일 수 있다:

• primitive values(원시 값)
• 하위 속성 및 값으로 이뤄진 객체(객체 형식은 [RFC7159]의 4절에 정의됨)인 경우, 복합 속성으로 간주됨(SHALL)
  • 복합 속성과 마찬가지로, 하위 속성의 순서는 중요하지 않음
  • 사전 정의된 하위 속성은 다중 값 속성 객체와 함께 사용될 수 있으나, 이 하위 속성들은 여기서 정의한 의미로만 사용해야 함(MUST)

특별히 정의되지 않은 경우, 다중 값 속성에 대한 기본 하위 속성 세트는 다음과 같음:

• type: 속성의 기능을 나타내는 라벨
  • 예: "work" 또는 "home"
• primary: 이 속성에 대한 '기본' 또는 선호 속성 값인지를 나타내는 불리언 값
  • 예: 선호 우편 주소 또는 기본 이메일 주소
  • 기본 속성 값 "true"는 한 번만 나타나야 함(MUST)
  • 지정되지 않은 경우, "primary"의 값은 "false"로 가정됨(SHALL)
• display: 읽을 수 있는 이름(human-readable name)
  • 주로 디스플레이 목적으로 사용되며, 변경 불가능성을 가짐(immutable)
• value: 속성을 나타내는 값
  • 예: 이메일 주소, 전화번호
• $ref: 참조 속성인 경우, 해당 리소스의 참조 URI
  • URI는 [RFC3986]의 6.2절에 따라 정규화(canonicalize)됨
  • 다른 SCIM 프로토콜 API 버전에서 리소스의 표현이 다를 수 있지만([RFC7644]의 3.13절 참조), API 버전이 있는 SCIM 리소스의 URI는 버전이 없거나 다른 버전의 URI와 비교할 수 있어야 함
    • 예를 들어, "https://example.com/Users/12345"는 "https://example.com/v2/Users/12345"와 동일함

서비스 제공자는 다중 값 속성을 정규화하여 반환해야 한다.(예: 이메일 주소 및 URL과 같이, 다중 값 속성의 하위 속성인 "type" 값은 "home” 또는 "work")(SHOULD)

서비스 제공자는 동일한 "value" 하위 속성을 가진 요소 객체를 각각 다른 "type" 하위 속성 쌍으로 한 개 이상 반환할 수 있다.(예: 동일한 이메일 주소가 work와 home에 사용될 수 있음)(MAY)

그러나 동일한 (type, value) 조합을 각 속성 당 하나 이상 반환하면 안된다.(SHOULD NOT)

클라이언트의 처리를 복잡하게 하기 때문이다.

다중 값 속성에 대한 스키마를 정의할 때, 값의 정규화 목적으로 사용될 수 있는 "type" 속성을 제공하는 것은 좋은 관행으로 간주된다.(MAY)

다중 값 속성에 대한 스키마 정의에서, 서비스 제공자는 권장되는 정규 값(7절 참조)을 정의할 수 있다.(MAY)

 

2.5. 할당되지 않은 값 및 Null 값

할당되지 않은 속성, null 값, 빈 배열(다중 값 속성에서)은 동등한 "state"로 간주되어야 한다.(SHALL)

속성에 "null" 값이나 빈 배열(다중 값 속성에서)을 할당하는 것은 "할당되지 않은" 상태와 동일한 효과를 가진다.

JSON 형식으로 표현된 리소스에서는 할당되지 않은 속성은(스키마에 정의되어 있다 하더라도) 간결함을 위해 생략될 수 있다.(MAY)

 

---

이 문서는 RFC 7643을 이해하기 쉽도록 한글로 재작성한 것입니다. 한글 표현에 대한 다양한 의견 환영합니다. 보다 정확한 내용이 궁금하신 분들은 원문(링크)을 참고 부탁드려요.