Files
egbim_qa_platform/docs/architecture_secretary_sso_role_access.md
root 33453ecc55
Deploy staging / deploy (push) Failing after 6s
Initial deployment setup
2026-08-31 16:45:24 +09:00

14 KiB

BARON-SSO 권한 및 접근 제어 설계

1. 문서 목적

본 문서는 BARON-SSO 연동 시점에 필요한 역할 분리, 테넌트 기반 1차 분기, 로그인 후 페이지 분기, 프로젝트 접근 제어 규칙을 별도로 정리한 문서임.

핵심 목적은 다음과 같음.

  • 개발자, 프로젝트 관리자, 사용자의 권한 범위를 명확히 구분함.
  • BARON-SSO tenant_id 와 우리 시스템의 페이지 분기 기준을 연결함.
  • BARON-SSO는 인증과 현재 테넌트 정보 제공까지만 담당하고, 최종 권한은 내부 DB에서 관리한다는 원칙을 고정함.
  • 프로젝트, 문의 구분, 관리자 콘솔 처리 구조를 현재 구현 방향 기준으로 문서화함.
  • 이후 실제 SSO 구현, 라우팅, 내부 권한 테이블 설계의 기준 문서로 사용함.

2. 적용 대상 범위

  • 인증 원본: BARON-SSO
  • 사용자 화면: /support/[workspaceCode]/new, /support/[workspaceCode]/list, /support/[workspaceCode]/[ticketId]
  • 관리자 콘솔: /main/project/[projectId]/feedback?channelId=[channelId]
  • 운영 보조 화면: /ops, /admin/issues
  • 제어 백엔드: apps/secretary-api
  • 관리자 API: apps/api

3. 역할 정의

역할 영문 역할명 주요 권한 접근 범위 로그인 후 기본 진입 화면
개발자 SYSTEM_ADMIN, SUPER_ADMIN 시스템 전체 설정, SSO 연동 관리, 프로젝트 생성 및 삭제, 권한 정책 변경 모든 프로젝트, 모든 관리자 기능 관리자 콘솔 또는 시스템 설정 화면
관리자 PROJECT_MANAGER 배정된 프로젝트의 피드백 조회, 댓글 처리, 이슈 연동, 권한 설정, 운영 분류 처리 내부 DB에 배정된 프로젝트 관리자 콘솔
사용자 END_USER, FEEDBACK_PROVIDER 피드백 작성, 본인 글 조회, 본인 글 상태 확인, 비밀글 작성, 공개된 Q&A 확인 본인이 진입한 프로젝트와 본인 작성 데이터 사용자 피드백 작성 페이지

4. 권한 모델 핵심 원칙

4.1 1차 판정 기준

  • 로그인 자체는 모두 BARON-SSO에서 처리함.
  • 우리 시스템은 BARON-SSO 세션 또는 userinfo 기준으로 최소 sub 또는 내부 매핑 가능한 식별자와 tenant_id 를 받음.
  • tenant_id 는 현재 사용자가 어떤 테넌트 문맥으로 진입했는지 확인하는 1차 분기 힌트로만 사용함.

4.2 2차 판정 기준

  • 로그인 성공 직후 내부 DB에서 사용자 매핑과 역할을 조회함.
  • 관리자 콘솔 진입 여부는 BARON-SSO 역할이 아니라 내부 DB의 프로젝트 관리자 권한으로 판단함.
  • 그 외 사용자는 일반 사용자로 처리함.
  • 추가 세부 권한은 우선 user + project + role 조합으로 제한하고, 채널 단위 권한은 추후 필요 시 확장함.

4.3 내부 권한 DB 책임 분리

  • BARON-SSO는 인증과 sso_sub, tenant_id 등 사용자 식별 문맥만 제공함.
  • baron_supportsupport_users, support_roles, support_role_assignments가 Secretary 사용자와 최종 권한의 원본임.
  • user_workspace_access는 역할 할당에 따른 workspace별 유효 권한을 저장하는 실행용 접근표임.
  • ABC User Feedback의 users, roles, members는 ABC 자체 피드백/관리자 콘솔 CRUD의 권한만 담당함.
  • Secretary의 일반 사용자/운영 권한을 ABC의 users.type, roles, members에서 조회하거나 추론하지 않음.

4.4 3차 판정 기준

  • 관리자 콘솔에 진입한 이후에는 프로젝트별 접근 권한을 다시 확인함.
  • 초기에는 전체 프로젝트 관리자만 두고, 채널 관리자는 운영 요구가 생길 때 별도 역할로 확장함.
  • 관리자 권한 설정은 관리자 콘솔의 별도 설정 페이지에서 처리함.

5. 테넌트 전략

5.1 테넌트 사용 원칙

  • BARON-SSO의 현재 테넌트 정보는 로그인 문맥과 초기 이동 경로를 정하는 보조 정보로 사용함.
  • 테넌트 자체를 권한의 최종 저장소로 사용하지 않음.
  • 관리자 여부와 프로젝트 접근 권한은 내부 DB에서 최종 판정함.

5.2 테넌트 기반 분기 규칙

BARON-SSO 테넌트 상태 기본 사용자 분류 기본 이동 경로 추가 분기
관리자 테넌트 문맥 내부 DB 확인 후 관리자 또는 사용자 관리자 콘솔 후보 경로 또는 사용자 경로 내부 DB 권한으로 최종 판정
일반 사용자 테넌트 문맥 사용자 프로젝트별 피드백 작성 페이지 본인 글 목록/상세 접근 허용

6. 로그인 후 페이지 분기 정책

6.1 관리자 후보 사용자

  • 로그인 성공 후 내부 DB에서 프로젝트 관리자 권한이 확인되면 관리자 콘솔로 이동함.
  • 기본 진입 후보 경로는 다음과 같음.
  • /main/project/[projectId]/feedback?channelId=[channelId]
  • 필요 시 운영 보조 화면 /ops, /admin/issues 로 이동 가능
  • 이후 프로젝트별 권한에 따라 진입 가능한 콘솔 페이지를 다시 제한함.

6.2 일반 사용자

  • 로그인 성공 후 각 소프트웨어 또는 서비스가 지정한 피드백 작성 페이지로 이동함.
  • 진입 URL에는 프로젝트/채널에 대응되는 workspaceCode 또는 서비스 식별자가 함께 전달됨.
  • 예시
  • /support/EGBIM/new
  • /support/TOVA/new
  • /support/GAIA/new
  • /support/KNGIL/new
  • /support/INTRANET_QNA/new

7. 프로젝트 및 채널 초기 운영 구조

7.1 초기 프로젝트 생성 대상

프로젝트명 설명 최초 기본 채널
EGBIM EGBIM 전용 Q&A EGBIM
TOVA TOVA 전용 Q&A TOVA
GAIA GAIA 전용 Q&A GAIA
KNGIL KNGIL 전용 Q&A KNGIL
INTRANET_QNA 인트라넷 공통 Q&A INTRANET_QNA

7.2 채널 운영 확장 계획

  • 최초에는 프로젝트당 채널 1개로 시작함.
  • 이후 각 프로젝트 내부에서 채널을 별도로 확장하여 문의 유형별로 분리 관리함.
  • 예시
  • EGBIM > 일반 문의, EGBIM > 장애 문의, EGBIM > 기능 개선
  • INTRANET_QNA > 계정 문의, INTRANET_QNA > 권한 문의, INTRANET_QNA > 시스템 오류

8. 사용자 진입 구조

8.1 기본 시나리오

  1. 사용자는 각 소프트웨어에서 이미 BARON-SSO 로그인 상태임.
  2. 사용자가 Q&A 이동 버튼을 클릭함.
  3. 소프트웨어는 자기 프로젝트에 대응되는 Q&A 진입 URL로 이동시킴.
  4. 우리 시스템은 세션에서 SSO 식별자와 tenant_id 를 읽음.
  5. 내부 DB에서 사용자와 프로젝트 관리자 권한을 조회함.
  6. 일반 사용자면 해당 프로젝트의 작성 페이지로 이동함.
  7. 프로젝트 관리자면 관리자 콘솔로 이동함.

8.2 프로젝트별 사용자 진입 예시

진입 서비스 사용자 이동 경로 프로젝트 관리자 이동 경로
EGBIM /support/EGBIM/new /main/project/[egbimProjectId]/feedback?channelId=[egbimChannelId]
TOVA /support/TOVA/new /main/project/[tovaProjectId]/feedback?channelId=[tovaChannelId]
GAIA /support/GAIA/new /main/project/[gaiaProjectId]/feedback?channelId=[gaiaChannelId]
KNGIL /support/KNGIL/new /main/project/[kngilProjectId]/feedback?channelId=[kngilChannelId]
인트라넷 Q&A /support/INTRANET_QNA/new /main/project/[intranetProjectId]/feedback?channelId=[intranetChannelId]

9. 문의 작성과 관리자 콘솔 분기 구조

9.1 기본 원칙

  • 사용자는 프로젝트 안에서 글을 작성함.
  • 글 작성 시 문의 구분 값을 함께 선택함.
  • 글 작성 시 필요하면 비밀글 여부를 함께 선택함.
  • 문의 구분 은 장기적으로 채널 또는 내부 workspace 분기 기준으로 사용함.
  • 관리자 콘솔에서는 프로젝트 단위로 유입 건을 구분하여 관리하고, 비밀글은 권한 있는 관리자만 열람 가능하도록 제한함.

9.2 현재 구조와 향후 확장 방향

항목 현재 기준 향후 확장 방향
프로젝트 서비스 단위 분리 유지
채널 프로젝트당 1개 기본 채널 필요 시 확장
문의 구분 사용자 작성 폼의 선택 값 운영 큐 분기 기준으로 사용
비밀글 작성 시 boolean 값 저장 역할별 조회 제한과 감사로그 추가
관리자 화면 프로젝트 단위 피드백 목록 프로젝트/문의구분 기반 다중 큐

10. 현재 구현 구조와의 연결 기준

10.1 사용자 화면

  • 현재 사용자용 지원 화면은 apps/web/src/pages/support/** 경로에 구성되어 있음.
  • 사용자 상세에서는 관리자 이슈 상태, 댓글, 본인 글 수정/삭제를 제공함.
  • 사용자 상세 상태 표시는 현재 ABC 원본 피드백의 연결 이슈 상태를 읽어 반영하도록 확장됨.

10.2 관리자 화면

  • 실제 관리자 콘솔은 apps/web/src/pages/main/project/[projectId]/feedback.tsx 경로를 중심으로 동작함.
  • 피드백 상세 시트에서 댓글 CRUD와 이슈 연결 상태를 확인할 수 있도록 연계됨.
  • 관리자 콘솔에서 이슈 연결 시 apps/apiapps/secretary-api 사이에서 내부 support_tickets.issue_link_status 를 함께 동기화하도록 보강됨.
  • 관리자 권한 설정 페이지는 관리자 콘솔 메뉴 항목으로 추가하는 방향을 기준으로 함.

10.3 제어 백엔드

  • apps/secretary-api 는 사용자 화면용 상태, 댓글, 내부 티켓 메타데이터를 관리함.
  • apps/api 는 ABC 관리자 콘솔의 피드백/이슈 기능을 제공함.
  • 장기적으로는 BARON-SSO 로그인 완료 후 내부 DB 권한 조회 결과를 기준으로 사용자 경로와 관리자 경로를 라우팅하는 정책 계층이 추가되어야 함.

11. 권한 처리 시퀀스

flowchart TD
    A[사용자 또는 관리자\nBARON-SSO 로그인 상태] --> B[Q&A 이동 버튼 클릭]
    B --> C[우리 시스템 진입]
    C --> D[세션에서 SSO 식별자와 tenant_id 확인]
    D --> E[내부 DB에서 사용자와 프로젝트 관리자 권한 조회]
    E --> F{프로젝트 관리자 권한 존재?}
    F -- 예 --> G[관리자 콘솔 진입]
    F -- 아니오 --> H[사용자 작성 페이지 진입]
    G --> I{프로젝트 접근 권한 존재?}
    I -- 예 --> J[프로젝트별 관리자 콘솔 페이지 진입]
    I -- 아니오 --> K[권한 없음 또는 다른 프로젝트로 재분기]
    H --> L[프로젝트별 사용자 작성 페이지 이동]
    L --> M[피드백 작성]
    M --> N[문의 구분 값과 비밀글 여부 저장]
    N --> O[프로젝트/문의구분 기준 관리자 콘솔 큐 반영]

12. 권한 매핑 테이블 초안

구분 BARON-SSO 값 우리 시스템 해석 화면 권한 데이터 권한
시스템 관리자 사용자 식별 정보 + tenant 문맥 내부 DB의 SUPER_ADMIN 전체 관리자 콘솔, 설정, 프로젝트 관리 전체 프로젝트
프로젝트 관리자 사용자 식별 정보 + tenant 문맥 내부 DB의 PROJECT_MANAGER 담당 프로젝트 콘솔, 권한 설정, 댓글/이슈 처리 배정 프로젝트
일반 사용자 사용자 식별 정보 + tenant 문맥 내부 DB 일반 사용자 또는 미승인 사용자 사용자 작성/목록/상세 본인 작성 글

13. 구현 시 체크리스트

  • BARON-SSO에서 내부 사용자 매핑에 사용할 식별 claim 확정
  • 프로젝트 EGBIM, TOVA, GAIA, KNGIL, INTRANET_QNA 생성
  • 각 프로젝트에 동일명 기본 채널 1개 생성
  • 프로젝트별 관리자 접근 정책 정의
  • 사용자 Q&A 이동 버튼의 프로젝트별 URL 매핑 정의
  • 로그인 후 내부 DB 권한 조회 기반 관리자/사용자 라우팅 구현
  • 문의 구분 값과 채널 분기 규칙 설계
  • 비밀글 저장, 조회 제한, 관리자 열람 규칙 설계
  • 프로젝트별 확장 채널 생성 전략 수립

14. 최종 정리

  • BARON-SSO는 인증과 현재 테넌트 문맥 제공 시스템임.
  • 최종 권한과 관리자 여부는 내부 DB가 결정함.
  • 일반 사용자는 프로젝트별 피드백 작성 페이지로 이동함.
  • 프로젝트 관리자는 담당 프로젝트의 관리자 콘솔로 이동함.
  • 초기에는 프로젝트당 채널 1개와 프로젝트 관리자 역할만 두고, 이후 필요 시 채널 관리자와 세분화 권한을 확장함.
  • 비밀글은 사용자 작성 기능과 관리자 조회 제한 정책에 포함해야 함.
  • 현재 구현된 사용자 화면, 관리자 콘솔, 내부 티켓/댓글/이슈 상태 동기화 구조는 이 권한 설계 문서를 기준으로 다음 단계 SSO 연동과 내부 권한 구현으로 연결할 수 있음.