DongHyeonkaandClaude Opus 5
b2963105a8
The keycloak project ended with four open questions that design could not
settle. A two-VM lab was built to answer them by measurement, and this is
that material: 26 experiments, 125 raw command outputs, 22 browser captures.
Follows the import procedure in README.md.
source/ the originating repository verbatim — 78 documents, 28 SVGs,
8 manifests, plus .source-revision recording the commit
final/ the SSOT
document.md 729 lines written from the 29 experiment documents, not
concatenated: what was predicted, what was measured, and
where the measurement itself was wrong
evidence/raw 125 outputs, flattened to <experiment>__<file> because
the originals collided (01-baseline.txt appeared three
times) and the audit only globs the top level
evidence/meta one per raw file; command and exitCode are null and the
README says why rather than inventing them
evidence/browser 22 captures
assets/ three diagrams through techviz
.techviz/ their VizSpecs
A separate project rather than an addition to keycloak: the B-layer answers
that project's four questions, but the A, C and D layers are about cluster
failure, SSO and operations, and one document.md should hold one subject.
The four question records there can point here through 관계.
Recorded rather than papered over: only three of the 28 diagrams were
remade. The repository forbids hand-drawn SVG and forbids titles inside the
canvas; all 28 originals carry both, so converting them is redrawing, not
reformatting. They stay in source/ and the gap is written into the document.
verify-pipeline.py passes. audit-records.py reports no issues.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
70 lines
3.6 KiB
Markdown
70 lines
3.6 KiB
Markdown
---
|
|
kind: CONCEPT
|
|
slug: messaging-admin-api-c03
|
|
title: 서명 대상 객체가 존재한다는 것이 4-eyes 통과를 뜻한다
|
|
topic: schema-and-wire-models
|
|
project: clean-architecture-backend-template
|
|
status: 게시 전
|
|
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
|
|
rootTreeNode: concept:messaging-admin-api-c03
|
|
evidenceCapturedOn: 2026-09-01
|
|
assets:
|
|
- key: messaging-admin-api-c03
|
|
file: ../../../final/evidence/rendered/messaging-admin-api-c03.svg
|
|
- key: messaging-admin-api-c03-diagram
|
|
file: ../../../final/assets/diagrams/messaging-admin-api-c03.svg
|
|
evidence:
|
|
- ../../../final/evidence/raw/messaging-admin-api-c03.txt
|
|
source:
|
|
- 원본 분석 절은 analysis/messaging/messaging-admin-api.md#L185 이다.
|
|
module: messaging-admin-api
|
|
---
|
|
|
|
# 서명 대상 객체가 존재한다는 것이 4-eyes 통과를 뜻한다
|
|
|
|
8개 필드. 그중 requestedBy 가 생성자에서 4-eyes 를 강제한다.
|
|
|
|
## 본문
|
|
|
|
<!-- body:start -->
|
|
|
|
`ApprovalGrant` 는 8개 필드다. 그중 `requestedBy` 가 생성자에서 4-eyes 를 강제한다. "우회할 수 없는 자리에 표현했다" — 검사기가 아니라 **record 생성자**에 두었으므로, 서명 대상 객체가 존재하는 것 자체가 4-eyes 통과를 뜻한다.
|
|
|
|
## canonicalForm 이 길이 접두 인코딩인 것
|
|
|
|
버전 접두 `"v1"` 이 앞에 있어 형식 교체 여지를 남긴 것도 의도적으로 보인다. 이 규칙이 계획 다이제스트 쪽에는 적용되지 않았다 — §12.3(b).
|
|
|
|
## 승인 검증이 도는 순서
|
|
|
|
:::evidence key="messaging-admin-api-c03-diagram" alt="다이제스트 대조에서 윈도우로 일치가 건너가고 윈도우에서 서명 파싱으로 기간 안이 건너가고 서명 파싱에서 HMAC 으로 형식 통과가 건너간다" caption="승인 검증이 도는 순서" zoom="false"
|
|
:::
|
|
|
|
**다이제스트 대조 → 윈도우 → 16진 파싱 → HMAC**. 다이제스트를 먼저 보는 이유가 주석에 있다.
|
|
|
|
## ApprovedReplayPlan 참조 위치
|
|
|
|
:::evidence key="messaging-admin-api-c03" alt="코드베이스에서 ApprovedReplayPlan 를 검색한 출력 11줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="ApprovedReplayPlan 코드베이스 검색 — 11줄 · exit 0" zoom="true"
|
|
:::
|
|
|
|
## 검증하는 쪽은 반드시 서명할 수도 있다
|
|
|
|
`sign(...)` 이 같은 클래스에 public 으로 있고, javadoc 이 그 위험을 스스로 명시한다. 이 문장과 대칭키 선택이 만드는 구조적 결과가 §17 의 한 항목이다.
|
|
|
|
## javadoc 이 세지 않는 두 검사
|
|
|
|
실제 분기는 여섯이다. 5번에는 별도 인라인 주석이 있어 의도된 검사임이 분명하다. "검사는 있는데 클래스 javadoc 이 세지 않는" 두 항목이, 동시에 **어떤 테스트에도 도달하지 않는** 두 항목이다(`EVD-303`, §12.1).
|
|
|
|
## dry run 을 항상 허용하는 근거
|
|
|
|
"the way to make operators plan before they act is to make planning free". 이것은 보안 완화가 아니라 행동 설계다.
|
|
|
|
## 토폴로지를 두 번 보는 이유
|
|
|
|
`ApprovedReplayPlan` 생성자(`:19-52`)와 `requireExecutable(now, currentTopologyVersion)`(`:54-85`)이 토폴로지를 **두 번** 본다. 승인이 서명된 토폴로지와 계획이 계산된 토폴로지가 다를 수 있으므로 둘 다 현재와 대조한다.
|
|
|
|
## 진행처럼 보이는 루프
|
|
|
|
`ApprovedRedrivePlan` 은 같은 네 검사에 더해 `loopAcknowledged` 를 별도 필드로 갖고, `requireExecutable` 의 마지막 분기가 그것을 강제한다. "진행처럼 보이는 루프" 는 이 리프에서 반복되는 관점이다 — 대시보드에서 옳아 보이는 실패를 타입으로 막는다.
|
|
|
|
<!-- body:end -->
|