ADR: 권한 체크 전략 선택

Status

Accepted

Context

AccountServer 프로젝트에서 여러 서비스 메서드에 권한 체크가 필요합니다.

서비스/메서드별 권한 요구 사항:

• AuthorityService
  • grantAuthority: 부여자가 해당 권한의 서비스 어드민인지 체크
  • revokeAuthority: 부여자가 해당 권한의 서비스 어드민인지 체크
  • createAuthority: 권한 부여자가 해당 서비스의 어드민인지 체크
  • updateAuthority: 권한 부여자가 해당 서비스의 어드민인지 체크
  • getAuthorities: 본인 권한 리스트만 조회 가능
• KeyValueService
  • getValue: 본인 것인지, 해당 서비스의 admin인지 체크
  • setValue: 본인 것인지 체크
• SystemService
  • createSystem: Super Admin만 가능
  • updateSystem: Super Admin 또는 해당 system admin 가능
  • getSystems: 해당 system admin만 가능

권한 종류:

• Super Admin
• System Admin (systemId 기반)
• 본인 소유(isMine)

Decision

일단 메서드 내부에서 Mono/Flux 기반 권한 체크를 수행하는 방식으로 구현합니다.

• 이유:

  1. Flux/Mono 체인을 유지하면서 권한 체크 수행 가능
  2. systemId 기반 조건, 본인 소유(isMine) 체크 구현 용이
  3. Reactive 방식과 자연스럽게 통합 가능

• 추후 필요 시 AOP 기반으로 전환하여 단순 권한 체크를 통합적으로 처리할 수 있도록 구조를 개선할 계획

Consequences

• Flux/Mono 반환 메서드에서 권한 체크를 쉽게 적용할 수 있음
• systemId 기반 admin 체크 및 복잡한 조건 처리 가능
• 코드 중복이 발생할 수 있으므로 공통 권한 체크 유틸리티를 도입 필요
• AOP를 사용한 권한 체크는 단순 조건에만 제한되지만, 향후 구조 개선 시 적용 가능

Alternatives Considered

1. AOP 기반 권한 체크
   • 장점: 코드가 깔끔하고 Spring과 통합됨
   • 단점: Flux/Mono 반환 메서드에서 복잡 조건 처리 어려움, 구현 난이도 높음
2. Mono.error 기반 메서드 내부 체크
   • 장점: 구현 쉽고 reactive 체인과 통합 가능, 복잡 조건 처리 가능
   • 단점: 코드 중복 발생 가능, 유지보수 난이도 증가