kevin/baron-sso
1
0
Fork 0
forked from baron/baron-sso
Code Pull Requests Activity
Files
0b8eaec636f8ffc64645ec72c467f4a48e10590a
baron-sso/docs/devfront-rp-relationships-guide.md

7.6 KiB
Raw Blame History

DevFront RP 관계 설정 가이드

이 문서는 DevFront의 RP 상세 화면 > 관계 탭에서 사용자에게 부여할 수 있는 관계 목록과 각 관계가 의미하는 기능 범위를 정리한다.

적용 범위

  • 대상 namespace: RelyingParty
  • 대상 화면: DevFront RP 상세 화면의 Relationships 탭
  • 대상 subject: 현재 1차 구현에서는 direct User:<kratosIdentityId> assignment
  • 기준 구현:
    • docker/ory/keto/namespaces.ts
    • devfront/src/features/clients/ClientRelationsPage.tsx
    • backend/internal/handler/dev_handler.go

기본 원칙

  • 관계 탭에서 부여하는 관계는 DevFront 운영 권한이다.
  • RelyingParty#access는 실제 서비스 로그인/접근 권한이며, DevFront 운영 권한과 별도이다.
  • 아래 수동 부여 관계 중 하나라도 있으면 해당 RP에 대한 기본 조회 권한(RelyingParty#view)도 함께 생긴다.
  • RP 관리자(admins)는 상위 관리 관계이며, 대부분의 세부 운영 권한을 포함한다.
  • 세부 관계는 필요한 기능만 최소 권한으로 부여할 때 사용한다.
  • creator는 생성 이력/자동 동기화용 내부 relation이며 관계 탭의 수동 부여 목록에는 노출하지 않는다.

관계 목록

화면 표시명 Relation key 의미 주요 허용 기능
RP 관리자 admins RP 운영 전반을 관리할 수 있는 관리자 관계 RP 조회, 설정 관리, secret 재발급, JWKS 운영, consent 조회/회수, 관계 조회, 감사 로그 조회, 상태 변경
RP 일반 설정 config_editor RP 이름, Redirect URI, 메타데이터 같은 일반 설정을 수정할 수 있는 관계 RP 조회, 일반 설정 수정
시크릿 재발급 secret_rotator Client secret 재발급과 rotation을 수행할 수 있는 관계 RP 조회, client secret 재발급
JWKS 조회 jwks_viewer JWKS 상태, 캐시 정보, key summary를 조회할 수 있는 관계 RP 조회, JWKS 상태/캐시/key summary 조회
JWKS 운영 jwks_operator JWKS refresh/revoke 같은 운영 작업을 수행할 수 있는 관계 RP 조회, JWKS 조회, JWKS refresh/revoke
동의 조회 consent_viewer 이 RP의 consent 내역을 조회할 수 있는 관계 RP 조회, 동의 및 사용자 목록 조회
동의 회수 consent_revoker 이 RP의 consent를 회수할 수 있는 관계 RP 조회, 동의 조회, 동의 회수
관계 조회 relationship_viewer 이 RP에 부여된 direct relation을 조회할 수 있는 관계 RP 조회, 관계 목록 조회
감사 로그 조회 audit_viewer 이 RP의 DevFront 감사 로그를 조회할 수 있는 관계 RP 조회, 해당 RP 감사 로그 조회
상태 변경 status_operator RP 활성/비활성 상태를 변경할 수 있는 관계 RP 조회, 활성/비활성 상태 변경

Permit 매핑

Keto namespace 기준으로 relation은 다음 permit으로 계산된다.

Permit 허용 relation / 조건 기능 의미
view admins, config_editor, secret_rotator, jwks_viewer, jwks_operator, consent_viewer, consent_revoker, relationship_viewer, audit_viewer, status_operator, 부모 tenant의 view 또는 view_dev_console RP 기본 조회 및 목록 노출
manage admins, 부모 tenant의 manage RP 관리 상위 권한
create creator, 부모 tenant의 grant_dev_permissions, manage RP 생성. creator는 현재 수동 부여하지 않는 내부 relation이다.
edit_config config_editor, manage RP 일반 설정 수정
rotate_secret secret_rotator, manage client secret 재발급/회전
view_jwks jwks_viewer, operate_jwks, manage JWKS 상태/캐시/key summary 조회
operate_jwks jwks_operator, manage JWKS refresh/revoke
view_consents consent_viewer, revoke_consents, manage consent 목록/상세 조회
revoke_consents consent_revoker, manage consent 회수
view_relationships relationship_viewer, 부모 tenant의 grant_dev_permissions, manage RP 관계 목록 조회
view_audit_logs audit_viewer, manage 해당 RP의 DevFront 감사 로그 조회
change_status status_operator, manage RP 활성/비활성 상태 변경
access access, manage 실제 서비스 로그인/리소스 접근

권한별 운영 예시

특정 사용자가 RP만 조회해야 하는 경우

최소 관계:

  • audit_viewer, consent_viewer, jwks_viewer 등 필요한 세부 조회 관계 중 하나

위 세부 관계는 모두 RelyingParty#view를 포함하므로, 사용자는 DevFront에서 해당 RP를 볼 수 있다.

특정 사용자가 동의 및 사용자 목록만 봐야 하는 경우

부여 관계:

  • consent_viewer

허용 결과:

  • RP 목록/상세 조회
  • 동의 및 사용자 목록 조회

허용하지 않는 기능:

  • 동의 회수
  • secret 재발급
  • JWKS refresh/revoke
  • 관계 부여/회수
  • 상태 변경

특정 사용자가 동의를 조회하고 회수도 해야 하는 경우

부여 관계:

  • consent_revoker

허용 결과:

  • revoke_consents permit
  • view_consents permit도 함께 허용

특정 사용자가 감사 로그만 봐야 하는 경우

부여 관계:

  • audit_viewer

허용 결과:

  • RP 목록/상세 조회
  • 해당 RP와 연결된 DevFront 감사 로그 조회

주의:

  • 감사 로그 필터링은 audit details의 target_id 또는 client_id가 RP client id와 일치하는지 기준으로 동작한다.
  • 오래된 로그 또는 일부 경로에서 target_id/client_id가 누락된 로그는 RP별 권한 사용자에게 보이지 않을 수 있다.

특정 사용자를 RP 운영 담당자로 지정해야 하는 경우

부여 관계:

  • admins

허용 결과:

  • manage permit
  • 대부분의 세부 운영 권한 허용
  • consent 조회/회수, 감사 로그 조회, 관계 조회, 상태 변경 등 포함

주의:

  • admins는 강한 권한이다.
  • 단순 조회나 특정 작업만 필요하면 세부 relation을 우선 사용한다.

자동 부여 관계

RP 생성 시 metadata.user_id가 존재하면 생성자에게 기본 운영 relation 세트가 outbox로 적재된다.

현재 자동 부여 대상:

  • admins
  • creator
  • config_editor
  • secret_rotator
  • jwks_viewer
  • jwks_operator
  • consent_viewer
  • consent_revoker
  • relationship_viewer
  • audit_viewer
  • status_operator

creator는 이 자동 부여 세트에는 포함되지만, 운영자가 관계 탭에서 수동으로 선택하는 관계는 아니다. 생성자 표시는 장기적으로 relation 부여 여부가 아니라 RP metadata 또는 audit read model 기반의 읽기 전용 정보로 제공하는 방향이 적절하다.

관련 tuple 예시

RelyingParty:client-a#admins@User:user-1
RelyingParty:client-a#consent_viewer@User:user-2
RelyingParty:client-a#consent_revoker@User:user-3
RelyingParty:client-a#audit_viewer@User:user-4
RelyingParty:client-a#relationship_viewer@User:user-5

운영 주의사항

  • 관계 부여/회수는 direct Keto write가 아니라 outbox 적재 방식으로 처리한다.
  • 관계를 부여한 직후 실제 Keto 반영까지 worker 처리 지연이 있을 수 있다.
  • 사용자가 DevFront에서 기대 권한을 얻지 못하면 다음을 우선 확인한다.
    • relation tuple의 subject가 실제 로그인한 Kratos identity id와 같은지
    • outbox worker가 tuple을 Keto에 반영했는지
    • 대상 RP의 client id가 tuple object와 같은지
    • audit/consent 로그에 client_id 또는 target_id가 정확히 기록되는지
View Git Blame Copy Permalink