docs(keycloak-session-store): import the session-storage lab as a new project

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>
2026-09-04 22:51:59 +09:00
parent 43bccd08a8
commit b2963105a8
5017 changed files with 372751 additions and 4943 deletions
@@ -3,7 +3,8 @@ id: 18a5cde2-dd1e-4bff-9f1c-997577ae438f
 kind: QUESTION
 slug: bff-session-authorized-client-store
 title: BFF의 Session과 OAuth2AuthorizedClient를 어디에 저장할 것인가
-topic: OAuth/OIDC 인증 경계
+topic: oauth-oidc-auth-boundary
+topicName: OAuth/OIDC 인증 경계
 project: KeyCloak Patterns
 status: 게시 중
 version: 32
@@ -3,7 +3,8 @@ id: 7ff40767-a00b-4db2-98f6-0cdfce8c8936
 kind: QUESTION
 slug: edge-authorization-scope
 title: Forward-Auth 구조에서 Application Authorization을 어디까지 Edge에 둘 것인가
-topic: OAuth/OIDC 인증 경계
+topic: oauth-oidc-auth-boundary
+topicName: OAuth/OIDC 인증 경계
 project: KeyCloak Patterns
 status: 게시 중
 version: 36
@@ -34,7 +35,7 @@ Role이나 권한처럼 애플리케이션의 기능과 밀접한 정보가 계

 - 지금 edge 응답은 user와 email만 전달한다. role과 groups, tenant, 인증 방식, token 만료는 전달하지 않는다.
 - upstream의 identity endpoint는 role을 확인하지 않는다. 누가 왔는지만 응답한다.
- 현재 Internal Token 검증은 특정 Controller에서만 수행하고 있으며, Security 설정에서는 해당 경로를 `permitAll`로 허용하고 있다. 
+- 현재 Internal Token 검증은 특정 Controller에서만 수행하고 있으며, Security 설정에서는 해당 경로를 permitAll로 허용하고 있다. 

  이 구조에서는 같은 내부 경로 아래에 새로운 Endpoint를 추가하더라도 Internal Token 검증이 자동으로 적용되지 않는다. 
  그래서 Filter, Interceptor, 또는 Spring Security의 인증 처리 단계처럼 공통 경계에서 검증하도록 옮겨야 한다.
@@ -62,7 +63,7 @@ Role이나 권한처럼 애플리케이션의 기능과 밀접한 정보가 계

 ### 1. 인증만 edge에 둔다

-Edge가 전달하는 Header를 `user`와 `email` 정도로 제한하면 Edge와 Upstream 사이의 계약을 작게 유지할 수 있다. 
+Edge가 전달하는 Header를 user와 email 정도로 제한하면 Edge와 Upstream 사이의 계약을 작게 유지할 수 있다. 
 Role이나 Permission 정보를 Header에 계속 추가하지 않으므로 Header 크기가 커지는 문제도 줄일 수 있다.

 이 경우 인가 판단은 각 Upstream 애플리케이션이 직접 수행한다. 
@@ -3,7 +3,8 @@ id: c72656b5-842d-45d9-b5f6-82b66b09d0b9
 kind: QUESTION
 slug: server-session-pattern-multi-instance
 title: 서버 세션 기반 인증 구조는 다중 인스턴스에서 어떻게 운영할 것인가
-topic: OAuth/OIDC 인증 경계
+topic: oauth-oidc-auth-boundary
+topicName: OAuth/OIDC 인증 경계
 project: KeyCloak Patterns
 status: 게시 중
 version: 39
@@ -3,7 +3,8 @@ id: 9ae4ec71-a32e-49a7-88c2-f7368541c28d
 kind: QUESTION
 slug: refresh-rotation-replica-contention
 title: Refresh Token Rotation과 다중 Replica 경쟁을 어떻게 처리할 것인가
-topic: OAuth/OIDC 인증 경계
+topic: oauth-oidc-auth-boundary
+topicName: OAuth/OIDC 인증 경계
 project: KeyCloak Patterns
 status: 게시 중
 version: 33