llm-wiki/raw/official-docs/spring-security-authorization-architecture.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 Architecture (AuthorizationManager, Method Security)	official-doc	https://docs.spring.io/spring-security/reference/servlet/authorization/architecture.html		feature-authentication-authorization-contract	ca-skeleton	authorization spring-security AuthorizationManager method-security PreAuthorize EnableMethodSecurity official-doc	2026-06-08	2026-06-08

Spring Security — Authorization Architecture (AuthorizationManager, Method Security)

Layer: raw/official-docs/ — Spring Security Reference 공식 문서. Authorization Architecture 페이지 + Method Security 페이지의 verbatim 발췌. feature-authentication-authorization-contract 의 enforcement mechanism axis 결정의 1차 근거.

Parent / 활용 branch (필수)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-authentication-authorization-contract	AuthorizationPort 포트 추상화 vs @PreAuthorize 직접 사용 vs web-layer authorizeHttpRequests 비교 — Spring layer 분리 근거

출처 / Source

• 원본 URL: https://docs.spring.io/spring-security/reference/servlet/authorization/architecture.html
• 보조 URL: https://docs.spring.io/spring-security/reference/servlet/authorization/method-security.html
• 아카이브 URL: (미수집)
• 저자 / 조직: Spring Security (Broadcom / Spring team)
• 발행일: rolling docs (현재 = 6.x / 7.0.0 API 포함)
• 마지막 확인일: 2026-06-08

왜 저장했는지 / Why archived

Spring Security 의 AuthorizationManager 가 supersede 한 기존 AccessDecisionManager / AccessDecisionVoter 와 달리, AuthorizationManager<T> 는 domain-neutral 인터페이스이므로 application layer 에 Spring Security 타입 없이도 custom AuthorizationManager<MethodInvocation> 을 구현할 수 있다는 사실을 grounding 하기 위해. @PreAuthorize 가 Spring AOP 를 통해 application layer 메서드에 직접 coupling 된다는 점도 기록.

핵심 인용 / Key quotes (verbatim)

[§AuthorizationManager] "AuthorizationManager supersedes both AccessDecisionManager and AccessDecisionVoter. Applications that customize an AccessDecisionManager or AccessDecisionVoter are encouraged to change to using AuthorizationManager."

[§AuthorizationManager] "AuthorizationManager instances make pre-invocation decisions on whether the invocation is allowed to proceed, and also post-invocation decisions on whether a given value may be returned."

[§AuthorizationManager] "Implementations are expected to return a positive AuthorizationDecision if access is granted, negative AuthorizationDecision if access is denied, and a null AuthorizationDecision when abstaining from making a decision."

[§AuthorizationManager interface] "The most common AuthorizationManager provided with Spring Security is AuthorityAuthorizationManager. It is configured with a given set of authorities to look for on the current Authentication. It will return positive AuthorizationDecision should the Authentication contain any of the configured authorities."

[§GrantedAuthority] "By default, role-based authorization rules include ROLE_ as a prefix. This means that if there is an authorization rule that requires a security context to have a role of 'USER', Spring Security will by default look for a GrantedAuthority#getAuthority that returns 'ROLE_USER'."

[§Method Security — @EnableMethodSecurity] "Then, you are immediately able to annotate any Spring-managed class or method with @PreAuthorize, @PostAuthorize, @PreFilter, and @PostFilter to authorize method invocations, including the input parameters and return values."

[§Method Security — integration with application layer] "Spring Security's method authorization support is handy for: Extracting fine-grained authorization logic; for example, when the method parameters and return values contribute to the authorization decision. Enforcing security at the service layer. Stylistically favoring annotation-based over HttpSecurity-based configuration."

[§Method Security — AOP coupling] "And since Method Security is built using Spring AOP, you have access to all its expressive power to override Spring Security's defaults as needed."

[§Method Security — Custom AuthorizationManager] "This gives use access the entire Java language for increased testability and flow control." (replacing SpEL with a custom AuthorizationManager)

[§Method Security — configuration] "You can place your interceptor in between Spring Security method interceptors using the order constants specified in AuthorizationInterceptorsOrder."

[§Method Security — request-level vs method-level tradeoff table] "| authorization type | coarse-grained (request-level) | fine-grained (method-level) |" "| configuration location | declared in a config class | local to method declaration |" "| authorization definitions | programmatic | SpEL |" "The main tradeoff seems to be where you want your authorization rules to live."

[§AuthorizationManagerFactory — Spring Security 7.0.0 API] "public interface AuthorizationManagerFactory { AuthorizationManager permitAll(); AuthorizationManager denyAll(); AuthorizationManager hasRole(String role); AuthorizationManager hasAnyRole(String... roles); ... }"

Claims Extracted / 추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
SS-AUTHZ-ARCH-C1	Spring Security 6+ 에서 AuthorizationManager 가 AccessDecisionManager / AccessDecisionVoter 를 supersede 함 — migration 권장	[§AuthorizationManager] "AuthorizationManager supersedes both AccessDecisionManager and AccessDecisionVoter. Applications that customize an AccessDecisionManager or AccessDecisionVoter are encouraged to change to using AuthorizationManager."	official-vendor-doc	Spring Boot 3.x / Security 6.x 환경	AuthorizationManager 가 framework 외부 포트로 안전하게 추상화될 수 있다는 것까지는 증명 안 함
SS-AUTHZ-ARCH-C2	@PreAuthorize 는 Spring AOP 를 통해 동작하므로, annotated class/method 는 Spring-managed bean 이어야 하고 Spring Security 의 SpEL 평가 인프라에 coupling 됨	[§Method Security] "And since Method Security is built using Spring AOP, you have access to all its expressive power..." + "you are immediately able to annotate any Spring-managed class or method"	official-vendor-doc	application layer use-case bean 에 @PreAuthorize 를 붙이는 패턴	@PreAuthorize 가 Clean Architecture 를 위반한다는 것은 직접 증명 안 함 — 그것은 architectural constraint 에서 오는 결론 (INFERENCE)
SS-AUTHZ-ARCH-C3	Custom AuthorizationManager<MethodInvocation> 을 구현하면 SpEL 대신 pure Java 로 authorization 로직을 작성할 수 있고, @EnableMethodSecurity(prePostEnabled = false) 후 custom interceptor 로 교체 가능	[§Method Security] "This gives use access the entire Java language for increased testability and flow control." + custom interceptor configuration snippet	official-vendor-doc	application layer 에서 Spring Security 의존 없이 포트 인터페이스만 의존하는 설계	custom AuthorizationManager 구현체 자체가 Spring-free 라는 것은 아님 — 구현체는 Spring bean 등록이 필요함
SS-AUTHZ-ARCH-C4	authorizeHttpRequests (web-layer rule) 은 coarse-grained 이며 config class 에 선언, method security 는 fine-grained 이며 method 선언에 local 함	[§Method Security] tradeoff table — "authorization type: coarse-grained	fine-grained"	official-vendor-doc	web-layer URL rule 만으로는 use-case 별 permission check 가 불가능하다는 근거
SS-AUTHZ-ARCH-C5	ROLE_ prefix 는 Spring Security 의 기본값 — role-based rule 은 ROLE_ prefix 를 자동으로 붙임	[§GrantedAuthority] "By default, role-based authorization rules include ROLE_ as a prefix."	official-vendor-doc	Keycloak realm role → ROLE_* authority 매핑 설계	ROLE_ 이 application-level permission 네이밍으로도 적합하다는 것은 아님
SS-AUTHZ-ARCH-C6	AuthorizationManagerBeforeMethodInterceptor + AuthorizationManagerAfterMethodInterceptor 로 pre/post authorization 을 분리 구성 할 수 있음	[§Method Security] "Advisor preAuthorize(MyPreAuthorizeAuthorizationManager manager) { return AuthorizationManagerBeforeMethodInterceptor.preAuthorize(manager); }"	official-vendor-doc	use-case 전/후 authorization 분리가 필요한 설계	이것이 가장 Clean Architecture 친화적 패턴이라는 것은 증명 안 함

Usage Boundaries / 적용 경계

• 이 자료가 직접 증명하는 것:
  • SS-AUTHZ-ARCH-C1: Spring Security 6.x 에서 AuthorizationManager 가 공식 표준 API
  • SS-AUTHZ-ARCH-C2: @PreAuthorize 는 AOP + Spring bean coupling 임
  • SS-AUTHZ-ARCH-C3: Custom AuthorizationManager 로 SpEL 을 Java 로 대체 가능
  • SS-AUTHZ-ARCH-C4: web-layer rule = coarse-grained, method-level = fine-grained
  • SS-AUTHZ-ARCH-C5: ROLE_ 은 Spring Security 기본 prefix
• 이 자료가 증명하지 않는 것:
  • @PreAuthorize 를 application-core 에 두는 것이 Clean Architecture 위반인지 — 이는 프로젝트의 architectural constraint 에서 오는 판단
  • AuthorizationPort 포트 패턴이 AuthorizationManager 보다 낫다는 것
  • RBAC vs ABAC 선택 — OWASP / 별도 자료 위임
• 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
  • application-core 모듈에서 AuthorizationManager<MethodInvocation> import 없이 포트 인터페이스만 의존하는 설계 패턴이 Spring Security 7.x 에서도 동일하게 작동하는지
  • @EnableMethodSecurity(prePostEnabled = false) 후 custom interceptor 만 활성화할 때 기존 Spring Security 보안 (CSRF, session 등) 에 영향이 없는지

메모 / Notes

• Spring Security 7.0.0 에서 AuthorizationManagerFactory 가 추가됨 (Spring Boot 3.5 에 포함 예정)
• @PreAuthorize 를 use-case (application-core) 에 직접 붙이면: (1) Spring Security 타입 import 필요, (2) AOP proxy 가 작동하려면 Spring bean 이어야 함, (3) SpEL 표현식은 compile-time 검증 없음 — 이 세 가지가 architectural constraint 위반 + 테스트 어려움의 원인
• Custom AuthorizationManager 는 AuthorizationManager<MethodInvocation> 을 구현하지만, 이 인터페이스 자체는 Spring Security import 임 → adapter layer (adapter-web) 에 두고, application-core 는 framework-free port interface 에만 의존하는 패턴이 필요

Related / 관련

• raw/official-docs/security-authorization-cheatsheet-owasp — deny-by-default, least-privilege 원칙
• raw/official-docs/spring-security-resource-server-jwt — JWT authority mapping
• raw/branch-notes/feature-authentication-authorization-contract