인증 및 접근 제어
D.Hub는 사용자 인증과 리소스 접근 제어를 위한 다층 보안 체계를 제공합니다. 로컬 인증, OIDC SSO, 서비스 토큰 등 다양한 인증 방식을 지원하며, 관계형 접근 제어(ReBAC)로 리소스별 세밀한 권한 관리를 구현합니다.
인증 방식 개요
D.Hub는 세 가지 인증 방식을 제공합니다. 환경과 용도에 따라 적절한 방식을 선택할 수 있습니다.
| 인증 방식 | 용도 | 토큰 유형 |
|---|---|---|
| 로컬 인증 | 사용자명/비밀번호 기반 직접 로그인 | JWT (Access + Refresh) |
| OIDC SSO | 외부 IdP를 통한 싱글 사인온 | JWT (Access + Refresh) |
| 서비스 토큰 | 자동화 스크립트, CI/CD 파이프라인 등 | 장기 유효 토큰 |
로컬 인증
로컬 인증은 D.Hub에 직접 등록된 사용자명과 비밀번호로 로그인하는 방식입니다.
인증 흐름
- 사용자가 로그인 화면에서 사용자명과 비밀번호를 입력합니다
- 서버가 비밀번호를 Argon2 해시와 비교하여 검증합니다
- 인증 성공 시 JWT Access Token과 Refresh Token이 발급됩니다
- 클라이언트는 이후 모든 API 요청에 Access Token을 포함합니다
JWT 토큰 구조
| 토큰 | 용도 | 유효 기간 |
|---|---|---|
| Access Token | API 요청 인증에 사용하는 Bearer 토큰 | 단기 (기본 30분) |
| Refresh Token | Access Token 만료 시 새 토큰 발급에 사용 | 장기 (기본 7일) |
Access Token이 만료되면 클라이언트는 Refresh Token을 사용하여 새로운 Access Token을 자동으로 발급받습니다. Refresh Token까지 만료된 경우 사용자는 다시 로그인해야 합니다.
OIDC SSO
OIDC(OpenID Connect) SSO를 통해 외부 IdP에서 관리하는 계정으로 D.Hub에 로그인할 수 있습니다. 사용자는 별도의 D.Hub 계정을 생성하지 않아도 기존 조직 계정으로 바로 접근할 수 있습니다.
지원 IdP
| IdP | 프로토콜 | 비고 |
|---|---|---|
| Keycloak | OIDC / OAuth 2.0 | 셀프 호스팅 IdP |
| Azure AD | OIDC / OAuth 2.0 | Microsoft 클라우드 IdP |
| Zitadel | OIDC / OAuth 2.0 | 클라우드 네이티브 IdP |
SSO 인증 흐름
SSO로 처음 로그인한 사용자는 D.Hub에 자동으로 등록되며, 이후 관리자가 사용자 관리 화면에서 역할을 지정할 수 있습니다.
서비스 토큰
서비스 토큰은 사람이 아닌 애플리케이션이나 자동화 스크립트가 D.Hub API를 호출할 때 사용하는 인증 수단입니다. 관리자가 발급하며, 일반 JWT와 동일하게 Bearer 토큰으로 사용합니다.
서비스 토큰 특징
- 장기 유효: 일반 Access Token과 달리 만료 기간이 설정되지 않습니다
- 역할 기반: 토큰에 특정 역할(
admin또는user)이 부여됩니다 - 감사 추적: 토큰을 통한 API 호출은 발급자 정보와 함께 기록됩니다
서비스 토큰은 만료되지 않으므로 자동화 스크립트, CI/CD 파이프라인, 외부 시스템 연동에서 사용하기 적합합니다. 단, 유출에 주의하여 환경 변수나 시크릿 매니저에 안전하게 보관하세요.
사용 예시
curl -H "Authorization: Bearer <SERVICE_TOKEN>" \
https://dhub.example.com/api/v1/datasets
인증 흐름 요약
접근 제어 (ReBAC)
D.Hub는 관계형 접근 제어(Relationship-Based Access Control, ReBAC)를 사용합니다. 전통적인 역할 기반 접근 제어(RBAC)와 달리, 사용자와 리소스 간의 관계를 기반으로 권한을 판단합니다.
핵심 개념
| 개념 | 설명 |
|---|---|
| 리소스(Object) | 접근 대상이 되는 D.Hub 내 항목 (Collection, Knowledge 등) |
| 관계(Relation) | 사용자/그룹과 리소스 사이의 역할 (owner, editor, viewer) |
| 사용자(User) | 접근 주체 (개인 사용자 또는 그룹) |
역할별 권한
| 역할 | 조회 | 편집 | 삭제 | 권한 관리 |
|---|---|---|---|---|
| viewer | ✅ | |||
| editor | ✅ | ✅ | ||
| owner | ✅ | ✅ | ✅ | ✅ |
역할은 계층적으로 작동합니다. owner는 editor의 모든 권한을, editor는 viewer의 모든 권한을 포함합니다.
접근 권한 설정
리소스의 설정 화면에서 사용자 또는 그룹에 접근 권한을 부여할 수 있습니다:
- 리소스(Collection, Knowledge 등)의 설정 탭으로 이동합니다
- 접근 제어 섹션에서 권한 추가 버튼을 클릭합니다
- 대상(개별 사용자 또는 그룹)을 선택하고 역할을 지정합니다
- 저장 버튼을 클릭하면 즉시 적용됩니다
그룹 기반 접근 제어
개별 사용자 대신 그룹에 접근 권한을 부여하면 효율적으로 관리할 수 있습니다. 그룹의 멤버십이 변경되면 해당 그룹을 통해 부여된 모든 리소스 접근 권한이 자동으로 반영됩니다.
그룹 "data-team" → Collection "sales-data" (editor)
├── alice (그룹 멤버) → sales-data 편집 가능
├── bob (그룹 멤버) → sales-data 편집 가능
└── carol (그룹 멤버) → sales-data 편집 가능
그룹 생성 및 멤버 관리에 대한 자세한 내용은 그룹 관리 문서를 참고하세요.
리소스를 생성한 사용자에게는 자동으로 owner 역할이 부여됩니다. Owner는 다른 사용자나 그룹에 권한을 추가하거나 제거할 수 있습니다.
다음 단계
| 문서 | 설명 |
|---|---|
| 사용자 관리 | 사용자 조회, 생성, OIDC 동기화 |
| 그룹 관리 | 그룹 생성, 멤버 관리, OIDC 동기화 |
| API Reference - Auth | 인증 API 상세 스펙 |