요약

  • RFC 3744는 주체(Principal)를 여러 URL을 가질 수 있는 웹 자원으로 취급했지만, ACE에서 그 주체를 참조할 때는 하나의 정식(canonical)DAV:principal-URL을 사용하도록 클라이언트에 요구했습니다.
  • 사람 이름 검색과 공개된 주체 컬렉션은 사용자가 후보를 찾는 데 도움을 주었습니다. 그러나 어느 쪽도 완전한 디렉터리를 약속하지 않았고, 누구를 인증하지도 않았으며, 접근 권한을 부여하지도 않았습니다.

화면의 이름은 규칙 속의 대상이 아니었다

2004년까지 WebDAV는 원격 문서와 컬렉션을 HTTP를 통해 편집 가능하게 만들었습니다. 이 확장의 접근 제어는 클라이언트가 어느 주체가 어떤 자원에 대해 어떤 작업을 수행할 수 있는지 표현할 수 있어야 했습니다. 매력적인 인터페이스는 이름 목록이었습니다. 그러나 프로토콜의 문제는 더 어려웠습니다. 이름은 인식을 위한 것이고, 접근 제어 항목(ACE)은 서버가 평가할 수 있는 참조가 필요하기 때문입니다.

2004년 5월에 발표된RFC 3744는 주체—사람 또는 계산 주체—를 네트워크 자원으로 표현했습니다. 동일한 주체가/u/256432와/people/Greg.Stein양쪽에서 접근 가능할 수 있습니다. 두 URL 모두 유효할 수 있으며, 클라이언트가 외견만으로 이들이 같은 주체를 가리킨다고 추론할 수는 없습니다. 사람이 읽을 수 있는DAV:displayname은 사람이 고르는 데 도움을 주지만, 신원 키는 아니었습니다.

따라서 RFC 3744는 정규화 단계를 마련했습니다. 클라이언트는 주체의 어떤 URL을 통해서든DAV:principal-URL을 조회할 수 있으며, 이 속성은 항상 동일한 지정 URL을 반환합니다. ACE를 생성할 때 클라이언트는 모든 별칭을 별개의 권한 주체로 취급하는 대신 주체의 URL 중 하나를 사용해야 했습니다. 그룹 멤버십도 동일한 참조 규칙을 따랐습니다. 그룹의 멤버 집합은 각 멤버의 주체 URL을 사용했습니다. 이를 통해 사용자 지향 URL이 서로 비슷하게 보일 필요 없이 프로토콜은 안정적인 참조를 확보했습니다.

이 구분이 중요했던 이유는 ACL이 자원에 부착되고 그 ACE는 권한을 부여하거나 거부할 주체를 지정하기 때문입니다. 한 클라이언트가 어떤 별칭으로 ACE를 작성하고 다른 클라이언트가 나중에 다른 별칭을 만나더라도, 클라이언트에는 일반적인 별칭 동등성 판정 수단이 없습니다. 정규화는 그 모호함을 각 클라이언트의 추측 대신 서버가 보호 속성으로 관리하는 영역으로 옮겼습니다.

검색은 의도적으로 디렉터리보다 좁았다

프로토콜은 사람 운영자가 수천 개일 수 있는 주체 사이에서 하나를 찾는 방법도 필요로 했습니다. RFC 3744는 선택된 속성에 대한 부분 문자열 검색인DAV:principal-property-search와, 어떤 속성이 검색 가능한지 클라이언트에 알려주는 별도의 리포트를 정의했습니다. 이는 사용자를 고정된 컬렉션 계층으로 강제하는 것보다 유연했지만, 모든 유용한 신원 속성을 질의할 수 있다는 약속은 아니었습니다.

그 경계는 명시적입니다. 서버는 검색에 사용할 수 있는 속성을 제한할 수 있습니다. 서버의DAV:principal-collection-set은 일부 컬렉션을 가리키거나 아무것도 가리키지 않을 수 있으며, 이 속성은 모든 주체의 완전한 우주를 보장하지 않습니다. 따라서 검색 결과는 어느 한 서버가 지원하는 검색 인터페이스가 노출한 후보일 뿐, 다른 주체가 존재하지 않는다는 증명도, 두 결과가 같은 사람이라는 증명도 아닙니다.

이 한계는 실무적 함의를 지닌 설계 선택이었습니다. 클라이언트는 검색 가능한 선택기를 제시한 뒤 선택된 자원을 주체 URL로 정규화할 수 있습니다. 그러나 별도의 시스템이 그 보장을 제공하지 않는 한, 그 선택기를 완전한 기업 디렉터리라고 진실하게 표현할 수는 없습니다. 검색은 “운영자가 의미하는 자원은 어느 것인가?”에 답했습니다. 정규화는 “ACL이 지명해야 할 주체 URL은 어느 것인가?”에 답했습니다.

어느 쪽도 “이 요청을 하는 사람은 누구인가?”에는 답하지 않았습니다. RFC 3744는 인증을 HTTP 메커니즘에 맡겼습니다. 서버가 ACE를 평가할 때 여전히 요청 주체를 검증하고 ACL을 적용해야 했습니다. 표시 이름, 검색 결과, 정식 URL, 인증 자격 증명, 부여된 권한은 제어 경로에서 서로 다른 기록입니다.

경계이지 완전한 신원 시스템이 아니었다

RFC 3744는 주체 자원이나 그룹이 어떻게 생성·유지되는지, 자원의 초기 ACL이 어떻게 설정되는지는 규정하지 않았습니다. 이 명세는 그런 시스템들을 둘러싼 상호운용 가능한 참조와 검색 리포트를 제공했습니다. 이 좁은 범위 덕분에 다양한 사용자 관리 저장소와 통합될 수 있었지만, 그만큼 디렉터리의 완전성과 수명 주기 거버넌스는 이 프로토콜의 바깥에 남았습니다.

이 명세의 역사적 기여는 URL이 사람의 실제 신원을 증명했다는 것이 아닙니다. 더 좁은 계약을 성립시킨 것입니다. 별칭이 존재할 수 있다는 점, 클라이언트는 ACL 참조를 위해 정식 주체 URL이 필요하다는 점, 검색은 서버 지원에 따라 한정된다는 점, 인증과 권한 부여는 별개의 확인이라는 점입니다. 운영자 지향 검색은 대상을 고르는 데 도움을 줄 수 있었지만, 대상을 정의하는 권위나 권한을 부여하는 권위가 되지는 않았습니다.

이 원문 기록이 확립하는 것은 표준 설계이며, 특정 제품의 채택 사례도, 현재 배포 현황 조사도, 실제 접근 사건도 아닙니다. 유용한 교훈은 구조적입니다. 검색 가능한 라벨, 안정적인 참조, 인증된 요청자, 유효한 권한은 하나의 인터페이스에 함께 표시된다고 해서 서로 바꿔 쓸 수 있는 것이 아닙니다.

출처