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 기본 시나리오
- 사용자는 각 소프트웨어에서 이미 BARON-SSO 로그인 상태임.
- 사용자가 Q&A 이동 버튼을 클릭함.
- 소프트웨어는 자기 프로젝트에 대응되는 Q&A 진입 URL로 이동시킴.
- 우리 시스템은 세션에서 SSO 식별자와
tenant_id 를 읽음.
- 내부 DB에서 사용자와 프로젝트 관리자 권한을 조회함.
- 일반 사용자면 해당 프로젝트의 작성 페이지로 이동함.
- 프로젝트 관리자면 관리자 콘솔로 이동함.
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. 권한 처리 시퀀스
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 연동과 내부 권한 구현으로 연결할 수 있음.