# Ory Keto (ReBAC) 네임스페이스 및 권한 상속 다이어그램

이 문서는 `docker/ory/keto/namespaces.ts`에 정의된 Baron SSO 프로젝트의 Ory Keto(ReBAC) 네임스페이스와 각 네임스페이스 간의 권한 상속(Permits) 및 관계(Relations)를 나타내는 Mermaid 다이어그램입니다.

## 네임스페이스 설계 구조

Ory Keto는 다음과 같은 4개의 주요 네임스페이스로 구성되어 있습니다:

1. **`User`**: 권한의 주체가 되는 기본 사용자.
2. **`System`**: 시스템 전역 권한 (최고 관리자 및 인증된 사용자).
3. **`Tenant`**: 조직/회사/부서 등 모든 형태의 격리 공간. 상위-하위(`parents`) 계층 구조를 가짐.
4. **`RelyingParty`**: OIDC 클라이언트(앱/리소스). 특정 `Tenant`에 종속될 수 있음.

---

## Mermaid 다이어그램

```mermaid
classDiagram
    class User {
        <<Namespace>>
    }

    class System {
        <<Namespace>>
        -- Relations --
        super_admins: User[]
        authenticated_users: User[]
        -- Permits --
        manage_all: super_admins
    }

    class Tenant {
        <<Namespace>>
        -- Relations --
        owners: User[]
        admins: User[] | SubjectSet~System, super_admins~
        members: User[]
        parents: Tenant[]
        developer_console_viewer: User[]
        developer_console_grant_manager: User[]
        -- Permits --
        view: members OR admins OR parents.view
        manage: admins OR owners OR parents.manage
        manage_admins: owners OR parents.manage_admins
        create_subtenant: manage
        view_dev_console: developer_console_viewer OR grant_dev_permissions OR manage OR parents.view_dev_console
        grant_dev_permissions: developer_console_grant_manager OR manage_admins OR parents.grant_dev_permissions
    }

    class RelyingParty {
        <<Namespace>>
        -- Relations --
        admins: User[]
        parents: Tenant[]
        access: User[] | SubjectSet~Tenant, members~ | SubjectSet~System, authenticated_users~
        creator: User[]
        config_editor: User[]
        secret_rotator: User[]
        jwks_viewer: User[]
        jwks_operator: User[]
        consent_viewer: User[]
        consent_revoker: User[]
        relationship_viewer: User[]
        audit_viewer: User[]
        status_operator: User[]
        -- Permits --
        view: admins OR direct operator relations OR parents.view OR parents.view_dev_console
        manage: admins OR parents.manage
        create: creator OR parents.grant_dev_permissions OR manage
        edit_config: config_editor OR manage
        rotate_secret: secret_rotator OR manage
        view_jwks: jwks_viewer OR operate_jwks OR manage
        operate_jwks: jwks_operator OR manage
        view_consents: consent_viewer OR revoke_consents OR manage
        revoke_consents: consent_revoker OR manage
        view_relationships: relationship_viewer OR parents.grant_dev_permissions OR manage
        view_audit_logs: audit_viewer OR manage
        change_status: status_operator OR manage
        access: access OR manage
    }

    %% Relationship lines indicating references (SubjectSets or Direct inclusion)
    User ..> System : super_admins, authenticated_users
    User ..> Tenant : owners, admins, members, developer_console_*
    User ..> RelyingParty : admins, access, operators

    Tenant "1" --> "*" Tenant : parents (상위 조직 상속)
    Tenant ..> RelyingParty : parents (소유권 상속)
    Tenant ..> RelyingParty : view_dev_console / grant_dev_permissions (범위 권한)
    Tenant ..> RelyingParty : access (members 접근 권한)

    System ..> RelyingParty : access (authenticated_users)

    %% Styling
    style User fill:#e1f5fe,stroke:#333,stroke-width:2px
    style System fill:#ffe0b2,stroke:#333,stroke-width:2px
    style Tenant fill:#fff9c4,stroke:#333,stroke-width:2px
    style RelyingParty fill:#e1bee7,stroke:#333,stroke-width:2px
```

### 권한 평가(Permit) 상세 로직 설명

- **Tenant (테넌트/조직):**
  - `view` (조회): 테넌트의 일반 멤버(`members`), 관리자(`admins`), 그리고 **상위 테넌트(parents)에서 조회 권한을 가진 자**가 조회할 수 있습니다.
  - `manage` (관리): 테넌트의 관리자(`admins`), 조직장(`owners`), 그리고 **상위 테넌트(parents)에서 관리 권한을 가진 자**가 관리할 수 있습니다.
  - `manage_admins`: 조직장(`owners`)과 상위 테넌트의 `manage_admins` 상속 권한으로 판정합니다.
  - `view_dev_console`: 직접 부여된 DevFront 조회 relation, `grant_dev_permissions`, `manage`, 상위 tenant 상속으로 판정합니다.
  - `grant_dev_permissions`: 직접 부여된 DevFront 권한 부여 relation, `manage_admins`, 상위 tenant 상속으로 판정합니다.

- **RelyingParty (OIDC 앱):**
  - `view` (조회): 앱의 직접 관리자(`admins`), 직접 운영 relation 보유자(`config_editor`, `jwks_viewer` 등), 또는 **이 앱을 소유한 테넌트(parents)에서 `view` 또는 `view_dev_console` 권한을 가진 자**가 조회할 수 있습니다.
  - `manage` (관리): 앱의 직접 관리자(`admins`) 또는 **이 앱을 소유한 테넌트(parents)에서 관리 권한을 가진 자**가 관리할 수 있습니다.
  - `edit_config`, `rotate_secret`, `operate_jwks`, `revoke_consents`, `change_status`: 각 직접 relation 또는 `manage`로 판정합니다.
  - `view_relationships`: 직접 `relationship_viewer`, 상위 tenant의 `grant_dev_permissions`, 또는 `manage`로 판정합니다.
  - `view_audit_logs`: 직접 `audit_viewer` 또는 `manage`로 판정합니다.
  - `access` (접근/로그인 가능 여부): 이 앱에 직접 접근 권한을 부여받은 유저/그룹(`access`), 또는 앱을 관리할 수 있는 권한(`manage`)을 가진 사람이 접근할 수 있습니다.
    - _접근 대상(access)은 특정 유저, 특정 테넌트의 전 멤버, 또는 전역 인증된 유저(System:authenticated_users)가 될 수 있습니다._

### 설계 원칙 메모

- `view_dev_console`는 RP 목록/기본 정보 조회 범위를 주는 tenant 범위 권한입니다.
- `view_dev_console`만으로 RP의 개별 운영 액션 permit이 자동 부여되지는 않습니다.
- `manage`는 1차 하위호환 permit으로 유지하며, 세부 permit이 완전히 backend/API에 반영되기 전까지 상위 호환 의미를 가집니다.