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

7.2 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)는 상위 관리 관계이며, 대부분의 세부 운영 권한을 포함한다.
  • 세부 관계는 필요한 기능만 최소 권한으로 부여할 때 사용한다.

관계 목록

화면 표시명 Relation key 의미 주요 허용 기능
RP 관리자 admins RP 운영 전반을 관리할 수 있는 관리자 관계 RP 조회, 설정 관리, secret 재발급, JWKS 운영, consent 조회/회수, 관계 조회, 감사 로그 조회, 상태 변경
RP 생성자 creator 이 RP를 생성한 운영 주체를 표시하거나 RP 생성 권한 모델에 연결되는 관계 RP 조회, RP 생성 정책과 연결
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 생성
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

관련 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