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

이 문서는 Baron SSO의 통합 권한 정책을 Ory Keto(Zanzibar 스타일 권한 엔진)에서 구현하기 위한 네임스페이스 설계와 관계 튜플(Relationship Tuples) 예제를 정의합니다.

0. 권한 흐름 다이어그램 (Permission Flow)

graph LR
    %% Subjects
    U[User: 사용자]
    
    %% Intermediate Groups
    subgraph Groups [유저 그룹 / 테넌트 관리 주체]
        UG_O[UserGroup: Owners / 그룹장]
        UG_M[UserGroup: Members / 멤버]
    end

    %% Resources
    subgraph Resources [테넌트 및 하위 자원]
        T[Tenant: 부모 테넌트]
        CT[Tenant: 자식 테넌트]
        RP[RelyingParty: 앱/클라이언트]
    end

    %% Relations (Solid = Direct, Dash = Inherited)
    U -- "owner of" --> UG_O
    U -- "member of" --> UG_M
    
    UG_O -- "becomes Admin of" --> T
    UG_M -- "gets View/Manage of" --> T
    
    T -- "controls" --> CT
    T -- "owns" --> RP
    
    %% Effective Permissions (Dash)
    U -. "inherits Admin" .-> T
    U -. "inherits Access" .-> CT
    U -. "can manage" .-> RP

    %% Styles
    style UG_O fill:#ff9,stroke:#333
    style T fill:#dfd,stroke:#333
    style RP fill:#bbf,stroke:#333

1. 네임스페이스 정의 (Namespaces)

네임스페이스	역할	비고
`Tenant`	격리된 자원 공간 (Workspace)	모든 유저 그룹은 테넌트의 한 종류임
`UserGroup`	사용자의 집합 (Specialized Tenant)	`Tenant` 네임스페이스를 상속하거나 호환됨
`RelyingParty`	OAuth2 클라이언트 앱	특정 테넌트에 소속됨
`System`	시스템 전역 권한	Super Admin 등을 관리

2. 핵심 정책의 Keto 구현

2.1 "모든 유저 그룹은 테넌트이다"

유저 그룹이 생성될 때, 해당 ID는 Tenant 네임스페이스에도 동시에 존재하며 동일한 상속 로직을 공유합니다.

2.2 "그룹장은 해당 테넌트의 어드민이다"

그룹장(Leader/Owner) 관계가 형성되면, Keto의 Subject Set 기능을 통해 테넌트의 admins 권한으로 자동 전파됩니다.

3. Keto 관계 튜플 예제 (Relationship Tuples)

Keto에 저장되는 데이터 포맷 예시입니다: namespace:object#relation@subject

3.1 사용자-그룹 관계 (Identity to Group)

설명	Keto 튜플 예제
그룹 멤버 추가	`UserGroup:dev-team#members@User:uuid-123`
그룹장 임명 (Leader)	`UserGroup:dev-team#owners@User:uuid-leader`

3.2 그룹-테넌트 권한 전파 (Group to Resource)

설명	Keto 튜플 예제
그룹장 -> 어드민 자동 상속	`Tenant:dev-team#admins@UserGroup:dev-team#owners`
그룹 -> 하위 테넌트 관리 권한	`Tenant:project-alpha#manage@UserGroup:dev-team#members`
그룹 -> 하위 테넌트 조회 권한	`Tenant:project-beta#view@UserGroup:dev-team#members`

3.3 테넌트-자원 소속 관계 (Hierarchy)

설명	Keto 튜플 예제
자식 테넌트 설정	`Tenant:child-dept#parents@Tenant:parent-corp`
앱(RP) 소속 테넌트 지정	`RelyingParty:auth-app#parents@Tenant:hanmac-family`

4. 권한 검증 로직 (Permission Check Logic)

시스템이 권한을 확인할 때(Check API) 사용하는 로직입니다.

4.1 그룹장의 테넌트 관리 권한 확인

사용자 uuid-leader가 dev-team 테넌트를 관리할 수 있는지 확인:

# 요청 (Check)
GET /relation-tuples/check?namespace=Tenant&object=dev-team&relation=manage&subject_id=uuid-leader

# Keto 내부 추론 경로
1. Tenant:dev-team#manage 권한은 Tenant:dev-team#admins에게 있음.
2. Tenant:dev-team#admins는 UserGroup:dev-team#owners를 포함함.
3. UserGroup:dev-team#owners에 User:uuid-leader가 존재함.
=> 결과: ALLOW (True)

4.2 그룹 멤버의 하위 자원(RP) 접근 확인

사용자 uuid-123이 auth-app 설정을 볼 수 있는지 확인:

# 요청 (Check)
GET /relation-tuples/check?namespace=RelyingParty&object=auth-app&relation=view&subject_id=uuid-123

# Keto 내부 추론 경로
1. RelyingParty:auth-app#view 권한은 부모인 Tenant:hanmac-family#view에 의존함.
2. Tenant:hanmac-family#view 권한은 UserGroup:dev-team#members에게 부여됨.
3. UserGroup:dev-team#members에 User:uuid-123이 존재함.
=> 결과: ALLOW (True)

5. 정책 요약 코드 (Namespace Config - DSL Style)

이 정책을 지원하기 위한 Keto 네임스페이스 설정 스키마 개념도입니다.

class Tenant implements Namespace {
  related: {
    admins: (User | UserGroup#owners)[]
    members: (User | UserGroup#members)[]
    parents: Tenant[]
  }

  permits: {
    view: (ctx: Context): boolean => 
      this.related.members.includes(ctx.subject) || 
      this.related.admins.includes(ctx.subject) ||
      this.related.parents.traverse((p) => p.permits.view(ctx)),
    
    manage: (ctx: Context): boolean => 
      this.related.admins.includes(ctx.subject) ||
      this.related.parents.traverse((p) => p.permits.manage(ctx))
  }
}

5.1 KiB Raw Blame History