Update 바론(Baron) SSO 통합 로그인 소개.md
This commit is contained in:
@@ -1,128 +1,73 @@
|
||||
# 바론(Baron) SSO 통합 로그인 소개
|
||||
# 바론 SSO와 Ory 스택 — 팀원 대상 설명
|
||||
|
||||
---
|
||||
|
||||
# 1. 제목
|
||||
- 바론 SSO 통합 로그인 소개
|
||||
|
||||
발표자 노트:
|
||||
- 인사 및 자기소개(30초)
|
||||
- 오늘 목표: 통합로그인 개념, 바론 SSO 아키텍처, 타 부서 통합 절차, 데모 계획(총 20분)
|
||||
## 목적(한 문장)
|
||||
팀원이 빠르게 이해하고 통합 작업을 시작할 수 있도록 Ory 컴포넌트와 바론 SSO 연동 방식을 실무 관점에서 설명합니다.
|
||||
|
||||
---
|
||||
|
||||
# 2. Agenda
|
||||
- 배경: 왜 SSO가 필요한가
|
||||
- 바론 SSO 개요(구성요소, 흐름)
|
||||
- 통합 방식 (개발팀이 할 일)
|
||||
- 보안/운영 고려사항
|
||||
- 데모 계획 및 다음 단계
|
||||
|
||||
발표자 노트:
|
||||
- 각 섹션별 시간안배: 배경 2분, 개요 5분, 통합 6분, 보안/운영 3분, 데모 3분, Q&A 1분
|
||||
## 핵심 개념 (짧고 명확하게)
|
||||
- Kratos: 사용자 계정·인증(로그인, 비밀번호, 세션)을 담당합니다. "누가 누구인지"를 관리합니다.
|
||||
- Hydra: OAuth2/OIDC 토큰을 발급합니다. 서비스(클라이언트)가 인증을 위해 의존하는 엔진입니다.
|
||||
- Oathkeeper: 서비스 앞단에서 토큰을 검사하고 요청을 허용/차단하는 프록시입니다.
|
||||
- Keto(옵션): 세부 권한(ACL/정책) 판정을 외부에서 처리합니다.
|
||||
|
||||
---
|
||||
|
||||
# 3. 왜 SSO인가? (Pain Points)
|
||||
- 여러 서비스별 계정 관리·비밀번호 문제
|
||||
- 사용자 온보딩/오프보딩의 복잡성
|
||||
- 인증 정책(비밀번호, MFA) 일관성 필요
|
||||
- 로그·감사 추적의 분산
|
||||
|
||||
발표자 노트:
|
||||
- 실제 사례(예: 계정 중복, 권한 잔존 문제)를 간단히 언급
|
||||
## 한눈에 보는 흐름 (개발자가 알아야 할 핵심 흐름)
|
||||
1. 사용자가 `userfront` 같은 서비스에 접근합니다.
|
||||
2. 서비스는 사용자에게 Hydra의 인증 페이지로 리디렉션합니다 (OIDC Authorization).
|
||||
3. 실제 로그인(아이디/비밀번호, MFA)은 Kratos에서 수행되고 세션이 만들어집니다.
|
||||
4. Kratos 인증 성공 후 코드가 Hydra로 돌아가고, Hydra는 토큰을 발급합니다.
|
||||
5. 발급된 토큰으로 서비스가 사용자 세션을 구성하고 리소스에 접근합니다.
|
||||
6. Oathkeeper가 앞단에 있으면 토큰 검증과 권한 시행은 중앙화됩니다.
|
||||
|
||||
---
|
||||
|
||||
# 4. 바론 SSO란?
|
||||
- 회사 내부 서비스의 통합 인증/인가 계층
|
||||
- OIDC/OAuth2 중심으로 서비스 인증을 통합 제공
|
||||
- 중앙에서 사용자, 권한, 세션을 관리
|
||||
|
||||
발표자 노트:
|
||||
- 바론 SSO는 우리 조직의 ID 게이트웨이로 작동
|
||||
- 핵심 목표: 개발자 경험 개선, 보안 표준화, 운영 간소화
|
||||
## 팀별 체크리스트 (쉽게 실행 가능한 항목)
|
||||
- 개발팀:
|
||||
- Hydra에 `client_id`/`redirect_uri` 등록
|
||||
- OIDC 라이브러리로 로그인 리디렉션/콜백 구현
|
||||
- 토큰(액세스/ID) 검증 구현 또는 Oathkeeper 사용
|
||||
- 보안팀:
|
||||
- 토큰 만료·리프레시 정책 검토
|
||||
- TLS, 시크릿 관리 정책 점검
|
||||
- 운영팀:
|
||||
- Ory 컴포넌트 모니터링(헬스체크, 로그 수집)
|
||||
- 스테이징/프로덕션 분리 및 백업 절차 수립
|
||||
|
||||
---
|
||||
|
||||
# 5. 핵심 구성 요소
|
||||
- Identity Provider (SSO 서버, 토큰 발급)
|
||||
- RP/Client(각 서비스, 예: `userfront`, `adminfront`, `orgfront`)
|
||||
- User DB / 로컬 사용자 동기화(선택적)
|
||||
- 인증 흐름(로그인, 토큰 발급, 세션 관리)
|
||||
|
||||
발표자 노트:
|
||||
- 리포지토리 구조에서 `adminfront`, `userfront`, `backend`가 어떻게 연결되는지 간단히 설명
|
||||
## 빠른 통합 단계 (실무 명령형)
|
||||
1. 로컬에서 스택 기동: `docker compose -f docker/compose.ory.yaml up` (환경변수 확인)
|
||||
2. Kratos 사용자 스키마 확인 및 필요시 매핑 수정
|
||||
3. Hydra에 서비스 클라이언트 등록(redirect URI, grant types, scopes)
|
||||
4. 프론트엔드에서 로그인 흐름 테스트(리디렉션 → 로그인 → 콜백)
|
||||
5. Oathkeeper 정책을 적용해 서비스 접근 제어 검증
|
||||
6. 통합 테스트 케이스를 작성해 반복 검증
|
||||
|
||||
---
|
||||
|
||||
# 6. 인증 흐름(요약)
|
||||
1. 사용자가 서비스 접속
|
||||
2. 서비스가 SSO로 리디렉션 (OIDC Authorization)
|
||||
3. SSO에서 인증 수행(암호, MFA, IDP 연동)
|
||||
4. 토큰 발급 후 서비스로 리턴
|
||||
5. 서비스는 토큰으로 사용자 세션 생성
|
||||
|
||||
발표자 노트:
|
||||
- 각 단계에서 어떤 로그/이벤트가 기록되어야 하는지 언급
|
||||
## 데모/점검 체크리스트 (발표·검증용)
|
||||
- 브라우저에서 서비스 접속 → SSO 로그인 흐름 정상 동작 확인
|
||||
- 토큰 클레임(`iss`, `aud`, `exp`)과 사용자 정보 정상 매핑 확인
|
||||
- Oathkeeper 사용 시, 인증 실패/권한 없음 케이스 확인
|
||||
- 로그(인증/토큰/권한 변경)가 중앙에 수집되는지 확인
|
||||
|
||||
---
|
||||
|
||||
# 7. 통합 방법(개발팀 가이드)
|
||||
- 지원 프로토콜: OIDC 권장 (SAML도 지원 가능)
|
||||
- 단계:
|
||||
1) 클라이언트 등록(redirect URI, client_id/secret)
|
||||
2) 로그인/로그아웃 엔드포인트 구현(또는 라이브러리 사용)
|
||||
3) 토큰 검증(액세스 토큰/ID 토큰) 및 사용자 매핑
|
||||
4) 권한 매핑(역할/스코프)
|
||||
5) 세션 만료·리프레시 정책 확인
|
||||
|
||||
발표자 노트:
|
||||
- 예시 라이브러리 또는 프레임워크별 샘플(원하시면 코드 스니펫 추가 가능)
|
||||
## 레포지토리 참조(빠른 위치)
|
||||
- Ory 관련 Compose 예시: [docker/compose.ory.yaml](docker/compose.ory.yaml)
|
||||
- 루트 배포 템플릿: [compose.ory.yaml](compose.ory.yaml)
|
||||
- 주요 서비스: `userfront`, `adminfront` (각 서비스는 Hydra 클라이언트로 등록 필요)
|
||||
|
||||
---
|
||||
|
||||
# 8. 보안 및 운영 고려사항
|
||||
- TLS/HTTPS 강제
|
||||
- 토큰 수명과 리프레시 정책
|
||||
- 로그/감사(특권 변경, 로그인 실패 등)
|
||||
- 비상 대응(사용자 차단, 세션 강제 만료)
|
||||
- 배포 환경(스테이징/프러덕션 분리, 시크릿 관리)
|
||||
|
||||
발표자 노트:
|
||||
- 감사 로그의 중앙 수집과 보존 정책을 강조
|
||||
## 다음 행동(권장)
|
||||
1. 각 팀은 위의 체크리스트 항목 중 담당 항목 선택 후 담당자·일정 등록
|
||||
2. 내가 도와줄 수 있는 작업: 클라이언트 등록 샘플, `docker compose` 실행 가이드, 프레임워크별 코드 스니펫 제공
|
||||
|
||||
---
|
||||
|
||||
# 9. 데모 계획 (간단)
|
||||
- 목표: 로그인 흐름 시연(서비스 → SSO → 서비스)
|
||||
- 준비물: 로컬 실행 가능한 서비스(예: `userfront`/`adminfront`) 또는 스테이징 환경
|
||||
- 간단한 시연 절차:
|
||||
1) SSO에 클라이언트 등록(이미 등록되어 있으면 생략)
|
||||
2) 브라우저에서 서비스 접근 → 리디렉션 및 로그인
|
||||
3) 토큰 수신 및 서비스 화면 확인
|
||||
|
||||
발표자 노트:
|
||||
- 현재 로컬 실행 방법을 원하시면 구체적 가이드를 추가 제공(예: `docker compose -f docker-compose.yaml up` 등)
|
||||
- 네트워크/포트 충돌에 대비한 사전 체크 권장
|
||||
|
||||
---
|
||||
|
||||
# 10. Q&A 및 다음 단계
|
||||
- 다음 단계 제안:
|
||||
- 각 팀별로 통합 계획 수립(담당자/일정)
|
||||
- 샘플 코드/SDK 제공
|
||||
- 스테이징 통합 테스트
|
||||
- 연락처/지원: (연락 가능한 채널 또는 담당자 표기)
|
||||
|
||||
발표자 노트:
|
||||
- 참석자별 액션 아이템을 정리해 배포 제안
|
||||
|
||||
---
|
||||
|
||||
|
||||
---
|
||||
|
||||
(부록) 참고 자료
|
||||
- 리포지토리 루트의 `README.md` 및 `docker/` 디렉터리 참조
|
||||
- 필요 시 PPTX 변환 또는 한국어 인쇄용 PDF로 변환 가능
|
||||
원하시면 이 문서에 실제 환경변수 목록, 포트/엔드포인트 예시, 또는 프레임워크별 코드 스니펫을 추가하겠습니다.
|
||||
|
||||
Reference in New Issue
Block a user