This commit is contained in:
@@ -0,0 +1,228 @@
|
||||
# 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 연동과 내부 권한 구현으로 연결할 수 있음.
|
||||
Reference in New Issue
Block a user