Ory Keto ReBAC 정책 및 관계 튜플 가이드

본 문서는 Baron SSO의 다형성 테넌트 구조를 지원하기 위해, Google Zanzibar 모델을 차용한 Ory Keto의 네임스페이스 및 관계 튜플(Relation Tuples) 설계 가이드를 정의합니다.

1. 중앙집중형 인가 백본 (Authorization Backbone)

복잡한 다단계 B2B2B 조직도 내에서의 상속 권한은 외부 백엔드의 RDBMS 논리만으로 실시간 검증하기에 과부하가 심합니다. 따라서 조직도나 권한이 변경될 때마다 이를 Keto의 관계 튜플로 실시간 변환/전송하고, 권한 검증(Check)은 초고속 병렬 처리가 가능한 Keto 엔진으로 오프로딩(Offloading)합니다.

2. 네임스페이스 (Namespaces)

과거 혼용되던 UserGroup 네임스페이스는 폐기되며, 철저한 권한 통제를 위해 아래 3개의 네임스페이스만 존재합니다.

Tenant: 모든 격리 공간 (회사, 지주사, 사내 부서, 개인 워크스페이스)
RelyingParty: 테넌트가 소유하는 자원/앱 (OIDC 클라이언트)
System: 테넌트에 종속되지 않는 전역 권한 (Super Admin 등)

3. 관계 튜플 규칙 (Relationship Tuples)

3.1 테넌트 계층 및 리더십

조직장 임명: Tenant:<조직ID>#owners@User:<유저ID>
어드민 자동 상속: Tenant:<조직ID>#admins@Tenant:<조직ID>#owners
테넌트 계층(부모-자식): Tenant:<하위ID>#parents@Tenant:<상위ID> (상위 테넌트의 admins는 하위 테넌트의 모든 권한을 상속받습니다.)

3.2 Relying Party (앱 자원) 제어 및 RP Admin

RP에 별도의 가상 테넌트를 만들지 않고, 자원 객체 자체의 다중 상속을 사용합니다.

앱 소유권 지정: RelyingParty:<앱ID>#parents@Tenant:<소유테넌트ID> (소유 테넌트의 최고 관리자가 앱 관리 가능)
전담 관리자(RP Admin) 직접 할당: RelyingParty:<앱ID>#admins@User:<유저ID>
Private 앱 접근 허용: RelyingParty:<앱ID>#access@Tenant:<소유테넌트ID>#members
Public 앱 접근 허용: RelyingParty:<앱ID>#access@System:authenticated_users#members

4. 트랜잭셔널 아웃박스를 통한 정합성 확보

Keto와의 데이터 일관성 문제는 시스템의 치명적인 아킬레스건입니다. 백엔드 DB에서 테넌트나 멤버십을 변경할 때, Keto API 직접 호출에 따른 부분 실패(Partial Failure)를 방지하기 위해 트랜잭셔널 아웃박스(Transactional Outbox) 패턴을 반드시 사용해야 합니다. DB 커밋과 함께 아웃박스 테이블에 튜플 이벤트를 기록하고, 비동기 릴레이 워커가 Keto로 동기화를 보장합니다. Soft delete 발생 시 즉각적으로 Keto의 튜플을 Hard delete 하여 권한을 회수합니다.

2.8 KiB Raw Blame History