[Developer] #617 apply DDS MCP end-user authorization
This commit is contained in:
@@ -8,8 +8,8 @@
|
||||
- 주 보호 객체: `ADMIN.CB_DDS_VECTOR_SEARCH_DOCUMENTS` (지식 청크·분류값 검색)
|
||||
- 보조 SQL 검증 객체: `ADMIN.V_DDS_CUSTOMERS_PG`, `ADMIN.V_DDS_CUSTOMERS_MY`
|
||||
- 보조 DDS SQL 검증 사용자: `dds_demo_my`, `dds_demo_pg`, `dds_demo_both`, `dds_demo_none`
|
||||
- 토큰 경로 기술 사용자: `dds_demo_token` (고객별 DDS 계정이 아님)
|
||||
- 조회 방식: 직접 DDS END USER 비교 경로 + 단일 기술 사용자·Bearer 토큰 경로
|
||||
- MCP SSE 경로: Bearer가 기존 업무 사용자를 식별하고 local DDS `END USER` Context로 실행
|
||||
- 레거시 토큰 데모 기술 사용자: `dds_demo_token` (비교·호환성 검증용)
|
||||
|
||||
## 두 데모의 관계
|
||||
|
||||
@@ -27,28 +27,29 @@
|
||||
|---|---|---|---|
|
||||
| VPD | 공통 계정 + Bearer/세션 컨텍스트 | 동적 predicate 함수 | 업무 권한 테이블 |
|
||||
| DDS 직접 비교 | DDS `END USER` 직접 로그인 | `DATA ROLE` + `DATA GRANT` | 선언형 DDL/Grant |
|
||||
| DDS 토큰 경로 | 단일 DDS 기술 사용자 + Bearer → `CB_AGENT_CTX` | 객체별 `DATA GRANT` predicate + 공통 `CB_*` | 요청 시 공통 권한 재평가 |
|
||||
| DDS MCP SSE | Bearer → `CB_APP_USER` → local `DDS_U_<id>` Context | `DATA ROLE` + `DATA GRANT` | 권한 변경 시 bulk 재게시 |
|
||||
| DDS 레거시 토큰 데모 | 단일 DDS 기술 사용자 + Bearer → `CB_AGENT_CTX` | 객체별 `DATA GRANT` predicate + 공통 `CB_*` | 요청 시 공통 권한 재평가 |
|
||||
|
||||
따라서 두 인스턴스의 관리 흐름과 기대 결과를 맞출 수 있습니다. 토큰 경로는 `DATA GRANT`의 `ON` 대상과 `WHERE` predicate를 사용하면서, 토큰 자체는 먼저 신뢰된 Context로 해석합니다. IAM 토큰을 DDS의 순수 `EndUserSecurityContext`로 전달하는 방식은 별도 확장 경계입니다.
|
||||
MCP SSE 경로는 Confidential Application의 OCI IAM database-access token으로 Context attach를 승인받지만, 업무 사용자 관리는 IAM으로 이전하지 않는다. 기존 `CB_APP_USER`/그룹/역할/permission이 source of truth이고 DDS는 이를 사용자별 보안 주체로 투영한다.
|
||||
|
||||
권한 변경 후에는 다음 순서로 확인합니다.
|
||||
|
||||
```text
|
||||
1. /permissions에서 사용자·그룹·역할·행/TAG·컬럼 기준을 저장
|
||||
2. /dds-provision에서 사용자별 predicate와 제외 컬럼을 검토
|
||||
3. 승인된 경우에만 DDS DATA GRANT 게시
|
||||
4. /vector-knowledge에서 토큰 기반 공통 권한 결과를 검증
|
||||
2. 저장 직후 활성 사용자의 MCP local END USER/DATA ROLE/DATA GRANT를 bulk 재게시
|
||||
3. /dds-provision에서 전체 재동기화·변경 검토·복구 게시
|
||||
4. /dds/mcp/sse의 `dds_vector_search`로 실제 MCP 권한 결과를 검증
|
||||
5. /dds에서 직접 END USER별 저수준 결과를 비교
|
||||
```
|
||||
|
||||
이 앱의 조회 경계는 다음과 같습니다.
|
||||
|
||||
```text
|
||||
Bearer → CB_AGENT_CTX → DATA GRANT predicate → DDS 보호 VIEW → 조회 결과
|
||||
MCP Bearer → CB_APP_USER → DDS_U_<id> Context → DATA ROLE/DATA GRANT → DDS 보호 VIEW → 조회 결과
|
||||
직접 비교: END USER → DATA ROLE → DATA GRANT → DDS 보호 VIEW
|
||||
```
|
||||
|
||||
ORDS Handler가 Bearer 값을 `cb_dds_hr` 같은 문자열로 바꾸는 것만으로는 DDS Context가 자동 생성되지 않습니다. 토큰 경로에서는 `CB_AGENT_CTX_PKG.SET_USER_BY_BEARER`가 해시·만료·회수·업무 사용자 매핑을 확인하고, 객체별 Data Grant predicate가 공통 권한 테이블을 조회합니다. 지원 드라이버의 `EndUserSecurityContext`를 사용하는 순수 DDS 경로는 별도 설계입니다.
|
||||
ORDS Handler가 Bearer 값을 문자열로 바꾸는 것만으로 DDS Context가 생성되지는 않습니다. MCP 경로는 JDBC `EndUserSecurityContext`를 SQL 실행 전에 attach하고, `finally`에서 해제한다. OCI IAM client-credentials token은 서비스 attach 권한만 나타내며, 사람 사용자는 기존 Bearer→업무 사용자 매핑으로 결정한다.
|
||||
|
||||
## 실행
|
||||
|
||||
|
||||
Reference in New Issue
Block a user