llm-wiki/raw/official-docs/spring-security-authorization-defense-in-depth.md

title, source_type, url, archive_url, related_branches, related_projects, tags, created, last_reviewed

title	source_type	url	archive_url	related_branches	related_projects	tags	created	last_reviewed
Spring Security — Authorization Overview (Defense in Depth — Request-Based + Method-Based)	official-doc	https://docs.spring.io/spring-security/reference/features/authorization/		feature-keycloak-spring-rs-role-mapping	keycloak-patterns	official-doc keycloak-patterns auth spring-security	2026-07-18	2026-07-18

Spring Security — Authorization Overview (Defense in Depth — Request-Based + Method-Based)

Layer: raw/official-docs/ — Spring Security Reference 공식 문서. Features > Authorization 최상위 개요 페이지의 verbatim 발췌. feature-keycloak-spring-rs-role-mapping 의 RBAC enforcement location Alternative C(request-level + method-level 동시 사용 = defense in depth) 결정의 1차 근거.

Parent / 활용 branch

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-keycloak-spring-rs-role-mapping	RBAC enforcement location Alternative C — request-level(authorizeHttpRequests) 과 method-level(@PreAuthorize) authorization 을 동시에 사용하는 defense-in-depth 조합이 Spring Security 가 벤더 차원에서 명명한 패턴이라는 근거

출처 / Source

• 원본 URL: https://docs.spring.io/spring-security/reference/features/authorization/
• 아카이브 URL: (미수집)
• 저자 / 조직: Spring Security (Broadcom / Spring team)
• 발행일: rolling docs (확인 시점 = Spring Security 7.1.0)
• 마지막 확인일: 2026-07-18

왜 저장했는지 / Why archived

Spring Security 공식 문서가 authorization 을 request-based 와 method-based 두 축으로 명시적으로 나누고, 이 둘을 함께 쓰는 것을 "defense in depth" 라고 벤더 자신이 직접 이름 붙였다는 사실을 grounding 하기 위해. 두 레이어가 서로 backstop 한다는 프레이밍이 이 페이지에만 등장하는 최상위 개요(overview) 텍스트이므로, 세부 구현 근거(raw/official-docs/spring-security-authorization-architecture)와 별도로 보관.

핵심 인용 / Key quotes (verbatim)

[§Authorization] "Spring Security provides defense in depth by allowing for request based authorization and method based authorization."

[§Authorization] "Authorization is determining who is allowed to access a particular resource."

[§Request Based Authorization] "Spring Security provides authorization based upon the request for both Servlet and WebFlux environments."

[§Method Based Authorization] "Spring Security provides authorization based on the method invocation for both Servlet and WebFlux environments."

[§Authorization] "Spring Security provides comprehensive support for authorization."

Claims Extracted / 추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
SS-AUTHZ-DID-C1	Spring Security 는 request-based authorization 과 method-based authorization 을 함께 허용함으로써 defense in depth 를 제공한다 — "defense in depth" 는 Spring Security 가 이 문서에서 직접 사용한 공식 벤더 용어	[§Authorization] "Spring Security provides defense in depth by allowing for request based authorization and method based authorization."	official-vendor-doc	Spring Security 6.x/7.x, Servlet + WebFlux 공통	두 레이어를 반드시 동시에 써야 한다거나, 이것이 모든 애플리케이션에 최적이라는 것은 증명 안 함 — "allowing for" (허용) 이지 "requiring" (강제) 이 아님. 두 레이어 조합의 구체적 wiring 방법(예: @PreAuthorize 와 authorizeHttpRequests rule 이 충돌할 때 우선순위)도 이 페이지엔 없음
SS-AUTHZ-DID-C2	Authorization 은 "누가 특정 리소스에 접근할 수 있는지 결정하는 것"으로 공식 정의됨	[§Authorization] "Authorization is determining who is allowed to access a particular resource."	official-vendor-doc	일반 정의 — 프레임워크·언어 무관 개념 정의 인용에 사용 가능	RBAC/ABAC 등 구체 모델 선택 근거는 아님
SS-AUTHZ-DID-C3	Request-based authorization 은 Servlet 과 WebFlux 환경 모두에서 지원됨	[§Request Based Authorization] "Spring Security provides authorization based upon the request for both Servlet and WebFlux environments."	official-vendor-doc	HTTP request 수준 gating (authorizeHttpRequests) 근거	request-based 단독으로 fine-grained(메서드 파라미터/리턴값 기반) 인가가 가능하다는 것은 증명 안 함
SS-AUTHZ-DID-C4	Method-based authorization 은 Servlet 과 WebFlux 환경 모두에서 지원됨	[§Method Based Authorization] "Spring Security provides authorization based on the method invocation for both Servlet and WebFlux environments."	official-vendor-doc	method invocation 수준 gating (@PreAuthorize 등) 근거	method-based 가 request-based 를 대체해야 한다는 것은 증명 안 함 — 이 페이지는 상호 배타가 아니라 병행 가능함만 말함
SS-AUTHZ-DID-C5	Spring Security 는 authorization 에 대해 "comprehensive support" 를 제공한다고 개요 페이지 서두에 명시	[§Authorization] "Spring Security provides comprehensive support for authorization."	official-vendor-doc	개요 수준 프레이밍 인용	구체적으로 무엇이 "comprehensive" 한지는 이 문장 자체로는 증명 안 됨 — 하위 링크(Authorize HTTP Requests, Method Security 등) 참조 필요

Usage Boundaries / 적용 경계

• 이 자료가 직접 증명하는 것:
  • SS-AUTHZ-DID-C1: Spring Security 벤더 문서가 request-based + method-based authorization 조합을 "defense in depth" 로 공식 명명함
  • SS-AUTHZ-DID-C3, SS-AUTHZ-DID-C4: 두 authorization 방식 모두 Servlet/WebFlux 양쪽에서 공식 지원됨
• 이 자료가 증명하지 않는 것:
  • 두 레이어를 반드시 동시에 써야 한다는 강제성 (이 페이지는 "allowing for" 표현 — 허용이지 강제가 아님)
  • feature-keycloak-spring-rs-role-mapping 의 구체 구현(@PreAuthorize("hasRole('admin-role')") 문법, JwtAuthenticationConverter 매핑 등)의 정확성 — 그건 raw/official-docs/spring-security-resource-server-jwt / raw/official-docs/spring-security-authorization-architecture 의 몫
  • request-level rule 과 method-level rule 이 충돌할 때의 우선순위나 평가 순서 — 이 개요 페이지엔 detail 없음
• 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
  • P3A 실제 구현에서 SecurityFilterChain.authorizeHttpRequests(...) 와 @PreAuthorize 를 함께 켰을 때 두 레이어가 실제로 독립적으로 평가되는지(하나가 다른 하나를 silently override 하지 않는지) 로컬 검증 필요

메모 / Notes

• 이 페이지는 Features > Authorization 최상위 랜딩 페이지 — "defense in depth" 프레이밍이 나오는 유일한 공식 페이지. 하위 세부 페이지(servlet/authorization/authorize-http-requests.html, servlet/authorization/method-security.html)는 각 메커니즘의 구체 API를 다루며 "defense in depth" 문구 자체는 반복하지 않을 수 있음 — 필요 시 별도 raw 로 발췌.
• Alternative C(request + method 동시 사용) 를 branch 결정으로 채택할 경우, 두 레이어의 구체 wiring 근거는 raw/official-docs/spring-security-authorization-architecture (AuthorizationManager, @PreAuthorize AOP coupling)를 함께 인용할 것.

Related / 관련

• raw/official-docs/spring-security-authorization-architecture — AuthorizationManager / method security 세부 구현 근거 (같은 vendor doc tree의 하위 페이지)
• raw/official-docs/spring-security-resource-server-jwt — JWT 기반 인증 + authority mapping (본 branch 의 authN 근거)