# 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_support`의 `support_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/api` 와 `apps/secretary-api` 사이에서 내부 `support_tickets.issue_link_status` 를 함께 동기화하도록 보강됨. - 관리자 권한 설정 페이지는 관리자 콘솔 메뉴 항목으로 추가하는 방향을 기준으로 함. ### 10.3 제어 백엔드 - `apps/secretary-api` 는 사용자 화면용 상태, 댓글, 내부 티켓 메타데이터를 관리함. - `apps/api` 는 ABC 관리자 콘솔의 피드백/이슈 기능을 제공함. - 장기적으로는 BARON-SSO 로그인 완료 후 내부 DB 권한 조회 결과를 기준으로 사용자 경로와 관리자 경로를 라우팅하는 정책 계층이 추가되어야 함. ## 11. 권한 처리 시퀀스 ```mermaid 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 연동과 내부 권한 구현으로 연결할 수 있음.