238 lines
9.1 KiB
Markdown
238 lines
9.1 KiB
Markdown
# Baron SSO 구조 분석
|
|
|
|
## 1. 이 시스템은 무엇인가
|
|
|
|
Baron SSO는 계열사 또는 화이트라벨 대상 서비스들의 로그인, 권한, 애플리케이션 연동을 중앙에서 관리하는 통합 인증/인가 허브입니다. 저장소의 설명과 구성 파일을 보면 단순 로그인 화면이 아니라 다음 역할을 함께 수행하는 IAM 플랫폼에 가깝습니다.
|
|
|
|
- 사용자 인증과 계정 수명주기 관리
|
|
- OAuth2/OIDC 기반 SSO와 RP(Relying Party) 연동
|
|
- 권한 정책 및 접근 제어 관리
|
|
- 관리자용 운영 화면, 개발자용 RP 관리 화면, 조직도/조직 컨텍스트 화면 제공
|
|
- 감사 로그 수집과 운영 데이터 관리
|
|
|
|
핵심적으로는 Ory Stack을 자체 호스팅하고, Baron Backend가 비즈니스 규칙과 운영 기능을 담당하며, 여러 프론트엔드가 역할별 UI를 제공합니다.
|
|
|
|
## 2. 전체 아키텍처 요약
|
|
|
|
현재 저장소는 하나의 애플리케이션이 아니라, 인증 인프라와 여러 사용자 인터페이스를 함께 운영하는 멀티 서비스 구조입니다.
|
|
|
|
### 2.1 주요 계층
|
|
|
|
1. Ory 기반 IAM 계층
|
|
2. Baron 자체 백엔드 계층
|
|
3. 역할별 프론트엔드 계층
|
|
4. 게이트웨이 및 인프라 계층
|
|
5. 데이터 저장소 및 로깅 계층
|
|
|
|
### 2.2 구성 요소별 역할
|
|
|
|
#### Ory Stack
|
|
|
|
`compose.ory.yaml` 기준으로 다음 컴포넌트를 별도 컨테이너로 운영합니다.
|
|
|
|
- Kratos: 사용자 인증, 계정, self-service flow
|
|
- Hydra: OAuth2/OIDC 서버, 로그인/동의 흐름, 토큰 발급
|
|
- Keto: 권한 관계 및 정책 기반 접근 제어
|
|
- Oathkeeper: 프록시형 접근 제어 게이트
|
|
|
|
즉, Baron SSO의 인증/인가 핵심은 Ory를 기반으로 하고, Baron 코드는 그 위에서 비즈니스 로직과 운영 기능을 덧씌우는 구조입니다.
|
|
|
|
#### Backend
|
|
|
|
`backend`는 Go Fiber 기반 API 서버이며, 저장소 README 설명대로 Ory Stack과 여러 프론트엔드 사이의 주된 비즈니스 백엔드 역할을 수행합니다.
|
|
|
|
역할은 다음과 같이 해석할 수 있습니다.
|
|
|
|
- 프론트엔드가 호출하는 자체 API 제공
|
|
- Ory Admin/Public API와 연동하여 로그인, 동의, RP 관련 흐름 제어
|
|
- 감사 로그 적재
|
|
- 테넌트, 사용자, 운영 데이터 처리
|
|
- 외부 연동 기능 처리
|
|
|
|
`docker-compose.yaml`에서도 각 웹 프론트엔드가 `API_PROXY_TARGET=http://baron_backend:3000`으로 이 백엔드를 바라보도록 구성되어 있습니다.
|
|
|
|
#### 프론트엔드 계층
|
|
|
|
역할이 나뉜 여러 UI가 함께 존재합니다.
|
|
|
|
- `userfront`: 최종 사용자용 로그인/인증 UI, Flutter 기반
|
|
- `adminfront`: 관리자용 운영 UI, React/Vite 기반
|
|
- `devfront`: 개발자용 RP 및 연동 관리 UI, React/Vite 기반
|
|
- `orgfront`: 조직/컨텍스트 시각화 및 관리 성격의 UI, React/Vite 기반
|
|
|
|
프론트엔드가 분리되어 있다는 점은 이 시스템이 단일 로그인 페이지 수준이 아니라, 사용자 포털과 운영 포털을 함께 포함하는 플랫폼임을 보여줍니다.
|
|
|
|
#### Gateway
|
|
|
|
`gateway`는 Nginx 기반 컨테이너이며 외부 진입점 역할을 담당합니다. `compose.infra.yaml`에서 `public_net`에 연결되어 있고, `USERFRONT_PORT`를 외부로 노출합니다. 따라서 사용자가 처음 접근하는 표면은 게이트웨이 또는 Oathkeeper를 포함한 프록시 계층을 통해 노출되는 구조로 볼 수 있습니다.
|
|
|
|
#### 데이터 및 부가 인프라
|
|
|
|
저장소에는 인증 인프라용 저장소와 서비스 메타데이터용 저장소가 분리되어 있습니다.
|
|
|
|
- PostgreSQL: Baron 메타데이터 저장 및 Ory 데이터 저장소
|
|
- ClickHouse: 감사 로그 및 이벤트성 데이터 적재
|
|
- Redis: 캐시/세션성 또는 보조 저장소 용도
|
|
- Promtail, Blackbox Exporter, Vector: 로그/모니터링/전송 보조 구성
|
|
|
|
### 2.3 구조도
|
|
|
|
```mermaid
|
|
flowchart LR
|
|
User[User / Admin / Developer] --> Gateway[Nginx Gateway / Public Entry]
|
|
User --> WebApps[Frontends]
|
|
|
|
subgraph Frontend Layer
|
|
UF[userfront\nFlutter]
|
|
AF[adminfront\nReact + Vite]
|
|
DF[devfront\nReact + Vite]
|
|
OF[orgfront\nReact + Vite]
|
|
end
|
|
|
|
Gateway --> UF
|
|
AF --> BE
|
|
DF --> BE
|
|
OF --> BE
|
|
UF --> BE
|
|
|
|
subgraph Service Layer
|
|
BE[Baron Backend\nGo + Fiber]
|
|
end
|
|
|
|
subgraph IAM Layer
|
|
KR[Ory Kratos]
|
|
HY[Ory Hydra]
|
|
KE[Ory Keto]
|
|
OK[Ory Oathkeeper]
|
|
end
|
|
|
|
BE --> KR
|
|
BE --> HY
|
|
BE --> KE
|
|
OK --> KR
|
|
OK --> HY
|
|
OK --> KE
|
|
|
|
subgraph Data Layer
|
|
PG[(PostgreSQL)]
|
|
CH[(ClickHouse)]
|
|
RD[(Redis)]
|
|
end
|
|
|
|
BE --> PG
|
|
BE --> CH
|
|
BE --> RD
|
|
KR --> PG
|
|
HY --> PG
|
|
KE --> PG
|
|
```
|
|
|
|
## 3. 개발 기술 스택 정리
|
|
|
|
### 3.1 백엔드
|
|
|
|
- Language: Go 1.26.2
|
|
- Web Framework: Fiber v2
|
|
- ORM/DB access: GORM, PostgreSQL driver, `lib/pq`
|
|
- IAM/OIDC 관련: `coreos/go-oidc`, `golang.org/x/oauth2`, `go-jose`
|
|
- Cache/infra: Redis, ClickHouse
|
|
- Test: Testify, Testcontainers
|
|
- 기타 연동: AWS SDK v2, SES
|
|
|
|
즉, 백엔드는 Go 기반의 API 서버이면서 IAM 흐름을 직접 제어하는 오케스트레이션 계층입니다.
|
|
|
|
### 3.2 사용자 프론트엔드
|
|
|
|
`userfront/pubspec.yaml` 기준 스택은 다음과 같습니다.
|
|
|
|
- Framework: Flutter
|
|
- Language runtime: Dart SDK 3.10+
|
|
- State management: Riverpod
|
|
- Routing: go_router
|
|
- 기타: easy_localization, qr_flutter, mobile_scanner, shared_preferences
|
|
|
|
이를 보면 `userfront`는 웹 중심 React 앱이 아니라 Flutter 기반의 사용자 인증 UI이며, QR 로그인, 다국어, 로컬 상태 저장 등의 기능을 염두에 둔 구조입니다.
|
|
|
|
### 3.3 운영/관리 프론트엔드
|
|
|
|
`adminfront`, `devfront`, `orgfront`는 공통적으로 현대적인 React 프론트엔드 스택을 사용합니다.
|
|
|
|
- Framework: React 19
|
|
- Build tool: Vite 8
|
|
- Language: TypeScript 6
|
|
- Styling: Tailwind CSS, tailwindcss-animate
|
|
- UI primitives: Radix UI
|
|
- Data fetching/cache: TanStack Query
|
|
- Form/validation: react-hook-form, zod
|
|
- Auth client: oidc-client-ts, react-oidc-context
|
|
- HTTP client: axios
|
|
- Test: Vitest, Playwright
|
|
- Lint/format: Biome
|
|
|
|
`orgfront`는 여기에 `@xyflow/react`를 사용하고 있어 조직 구조나 컨텍스트 시각화 성격의 기능이 포함된 것으로 보입니다.
|
|
|
|
### 3.4 공통/모노레포 구성
|
|
|
|
- Package manager: pnpm workspace
|
|
- 공통 패키지: `common`
|
|
- 공통 리소스: `locales`
|
|
- 코드 품질: Biome
|
|
|
|
즉, 프론트엔드는 모노레포 형태로 운영되며 공통 UI/설정/로케일 자산을 공유합니다.
|
|
|
|
### 3.5 인프라 및 배포
|
|
|
|
- Container orchestration: Docker Compose
|
|
- Reverse proxy: Nginx
|
|
- IAM platform: Ory Kratos, Hydra, Keto, Oathkeeper
|
|
- Database: PostgreSQL
|
|
- Analytics/Audit store: ClickHouse
|
|
- Cache: Redis
|
|
- Observability: Promtail, Vector, Blackbox Exporter
|
|
|
|
## 4. 이 저장소에서 보이는 설계 특징
|
|
|
|
### 4.1 멀티테넌트 운영 시스템 성격
|
|
|
|
README와 `seed-tenant.csv`, 테넌트 import/export 관련 문서 이름들로 보아 이 시스템은 단일 서비스용 로그인 서버가 아니라, 여러 조직과 테넌트를 관리하는 멀티테넌트 IAM 운영 시스템입니다.
|
|
|
|
### 4.2 인증과 운영 기능의 분리
|
|
|
|
인증 그 자체는 Ory Stack이 맡고, Baron Backend와 각 Frontend가 다음을 담당합니다.
|
|
|
|
- 비즈니스 규칙 적용
|
|
- 운영 UI 제공
|
|
- 테넌트/사용자 관리
|
|
- RP 등록 및 OIDC 연동 관리
|
|
- 감사 로그와 운영성 기능
|
|
|
|
이 구조는 범용 IAM 엔진과 도메인 특화 운영 시스템을 분리한 설계로 볼 수 있습니다.
|
|
|
|
### 4.3 감사와 추적 가능성을 중시
|
|
|
|
ClickHouse, Promtail, Vector, 감사 로그 관련 README 설명을 보면 운영 추적성과 감사 가능성을 중요한 요구사항으로 두고 있습니다. 특히 로그인/권한/관리자 작업의 추적을 고려한 구조로 해석됩니다.
|
|
|
|
### 4.4 역할별 UI 분리
|
|
|
|
최종 사용자, 운영 관리자, 개발자, 조직 관리 성격의 UI가 분리되어 있어 권한과 업무 맥락에 따라 화면을 구분하는 B2B 운영 시스템의 전형적인 구조를 가집니다.
|
|
|
|
## 5. 한 줄 요약
|
|
|
|
Baron SSO는 Ory Stack을 자체 호스팅 기반으로 사용하면서, Go 백엔드와 여러 역할별 프론트엔드를 결합해 구성한 멀티테넌트 SSO/IAM 운영 플랫폼입니다. 기술적으로는 Go + Fiber, Flutter, React + Vite + TypeScript, PostgreSQL, ClickHouse, Redis, Docker Compose, Ory 생태계를 중심으로 구성되어 있습니다.
|
|
|
|
## 6. 분석 시 참고한 주요 근거 파일
|
|
|
|
- `README.md`
|
|
- `docker-compose.yaml`
|
|
- `compose.infra.yaml`
|
|
- `compose.ory.yaml`
|
|
- `backend/go.mod`
|
|
- `adminfront/package.json`
|
|
- `devfront/package.json`
|
|
- `orgfront/package.json`
|
|
- `userfront/pubspec.yaml`
|
|
- `pnpm-workspace.yaml`
|
|
|
|
## 7. 주의사항
|
|
|
|
루트 README의 일부 프로젝트 구조 설명은 현재 저장소의 실제 구성과 완전히 일치하지 않을 수 있습니다. 예를 들어 `adminfront`, `devfront`, `orgfront`는 실제로 React/Vite 기반 패키지이고, `userfront`는 별도의 Flutter 애플리케이션입니다. 따라서 현재 구조 분석은 README 서술보다 실제 매니페스트와 compose 파일을 우선 기준으로 정리했습니다. |