레거시 권한 정책 이식하기

이번 글에서는 eGov와 XML 설정 기반으로 되어 있던 인증/권한을 Spring Security기반으로 옮기면서 겪은 문제를 정리해보려고 한다.

문제 상황

Spring Security기반으로 인증 구조를 옮기면서 가장 먼저 드러난 문제는 '로그인이 되는가'가 아니었다.

로그인 자체는 가능했지만 로그인 이후의 권한이 기존 시스템과 다르게 동작했다.

예를 들면 다음과 같은 문제들이 있었다.

• 일반 권한의 사용자가 직접 URL을 호출하면 일부 관리자 화면에 접근 가능

• 관리자 계정이 기존에 접근하던 조회 화면에서 403이 발생

• 로그인 정책들이 적용되지 않음

• 새로 만든 권한 코드가 반영되지 않음

문제는 권한 관리 화면이 없다는 것이 아니었다.
기존 시스템에서 여러 설정, 세션, 테이블이 함께 처리하던 권한 판단 흐름을 Spring Security구조에서 다시 연결해야 하는 것이 문제였다.

원인

원인은 권한 정보가 없어서가 아니었다.

권한 정보는 있었다.
문제는 그 정보가 사용되는 위치가 달라졌다는 점이었다.

레거시 시스템에서는 eGov, XML 설정, 세션, 메뉴 권한, 로그인 정책이 함께 맞물려 있었다.

하지만 신규 프로젝트에서는 Spring Security가 인증과 접근 제어의 중심이 된다.

따라서 기존 세션 값이나 권한 테이블을 그대로 옮기는 것만으로는 부족했다.
그 값이 Authentication, SecurityContext, URL 접근 제어, 로그인 성공/실패 처리 흐름까지 이어져야 했다.

또 메뉴 권한과 URL 접근 제어는 서로 다른 계층이었다.

메뉴에서 숨겼다고 실제 요청이 막히는 것은 아니다.
반대로 URL 접근 제어를 너무 강하게 잡으면, 기존 관리자 계정이 사용하던 조회 화면까지 막힐 수 있다.

해결

먼저 권한 관련 흐름을 세 가지로 나눠서 봤다.

인증

기존 계정을 Spring Security에서 사용할 수 있도록 사용자 조회와 비밀번호 검증 흐름을 맞췄다.

단순히 로그인 폼을 붙이는 것이 아니라, 레거시 DB에서 어떤 값을 읽고 어떤 방식으로 비밀번호를 검증해야 하는지 확인했다.

세션

로그인 성공 시에는 필요한 사용자 정보와 권한을 세션에 담도록 했다.

반대로 로그인 실패 시에는 기존 로그인 객체와 SecurityContext가 남지 않도록 정리했다.
실패했는데 이전 세션 값이 남아 있으면, 다음 요청에서 예상하지 못한 상태가 생길 수 있기 때문이다.

인가

메뉴 노출과 URL 접근 제어를 분리해서 확인했다.

메뉴 권한은 사용자가 어떤 메뉴를 볼 수 있는지를 결정한다.
URL 접근 제어는 사용자가 요청했을 때 허용할지를 결정한다.

로그인 정책은 실제 로그인 요청 앞단에서 검사하도록 했다.

• IP 제한 값이 있으면 로그인 전에 현재 IP와 비교한다.

• 중복 로그인이 금지된 사용자는 이미 활성 세션이 있는지 확인한다.

• 조건에 맞지 않으면 인증 로직으로 들어가기 전에 차단한다.

테스트

• 권한이 없는 사용자가 URL을 직접 호출하면 403이 나는가

• 로그인 실패 후 기존 세션 값이 정리되는가

• 로그인 성공 후 권한에 맞는 시작 화면으로 이동하는가

• 기존 관리자 계정은 필요한 조회 화면에 계속 접근할 수 있는가

• IP 제한 정책이 실제 로그인 요청에서 적용되는가

• 중복 로그인 제한 정책이 적용되는가

• 새로 만든 권한 코드가 메뉴 매핑과 런타임 권한 정보에 함께 반영되는가

정리

이번 작업을 하면서 인증/권한 마이그레이션은 설정 파일을 옮기는 일이 아니라, 권한을 판단하는 흐름을 새 구조에 다시 연결하는 일에 가깝다는 것을 느꼈다.

로그인 실패 후 세션이 정리되는지, 로그인 성공 후 권한에 맞는 시작 화면으로 이동하는지, 메뉴 권한과 URL 접근 제어가 같은 기준을 바라보는지, 기존 관리자 계정의 조회 동선이 깨지지 않는지까지 함께 확인해야 했다.

결국 인증/권한 이식의 핵심은 '로그인이 되는가'가 아니라, 로그인 이후 권한을 판단하는 흐름이 기존 시스템과 같은 의미로 이어지는가였다.