본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
안녕하세요 :)
오늘은 챌린지 36일차로, 오랜만에 새벽 공부를 다시 하고 자려 합니다.
오늘 배울 내용은,
Part B. 스프링 시큐리티 심화
Ch 4. 사전 및 사후 권한 부여/필터링
"03. 사후 권한 부여" 입니다.
오늘은 사후 권한 부여에 대해서 알아보았다. 사전 권한 부여는 규칙에 따라 아예 메소드 호출이 제한되었다. 반대로 사후 권한 부여는 메소드 호출은 조건 여부와 관계없이 허용한다. 하지만 권한 조건을 충족해야 결과값을 반환하도록 허용한다.
어떤 상황에서 사후 권한 부여가 필요할까? 예를 들어, 데이터베이스에서 데이터를 조회한 결과를 반환하는 엔드포인트가 있다고 가정을 해보자. 원하는 기능은 조회한 결과를 기준으로 반환을 할지 말지를 판단해야 하는 상황이다. 따라서 데이터베이스에서 조회를 하기 전에는 알 수 없다.
사후 권한 부여 적용 예시에 대해 살펴보자.
Employee 라는 직원 클래스가 존재하는데, 각 직원은 1개 이상의 역할을 가지고 있을 수 있다. 그 역할에 따라 그 직원이 읽은 책을 반환할지를 판단하고 싶다. BookService 에 @PostAuthorize 를 적용하고, 반환되는 returnObject 의 roles 필드에 engineer 가 포함되어 있으면 반환하고, 그렇지 않으면 반환하지 않는다. roles 필드를 조회해야 하기 때문에 @PreAuthorize 로는 해결할 수 없다. 별도의 데이터베이스를 연결하지 않고, 쉽게 해결하기 위해 map 을 활용한다. 엔드포인트에서 name 을 전달받고, 입력받은 name 으로 map 을 조회하여 engineer 역할이면 결과값을 반환한다.
조금 더 복잡한 상황을 생각해보면, 사전 권한 부여에서는 hasAuthority, 사후 권한 부여에서는 returnObject.roles.contains 를 활용하는 등 어떠한 표현식 기반으로 기능을 알아보면, 이러한 표현식은 알기도 어려울 뿐더러 버그가 생길 가능성이 높고, 한 줄로 표현이 어렵거나 복잡한 권한 부여 규칙의 경우에는 적용하기가 어려울 수 있다.
이 문제를 어떻게 해결할 수 있을까? 바로 권한 부여 규칙을 담고 있는 별도의 클래스를 생성하여 해결할 수 있다. 예를 들면 다음과 같다. 문서를 관리하는 애플리케이션으로 모든 문서에는 각 문서의 담당자가 존재하고, 문서의 세부 정보를 원기 위해서는 클라이언트는 "관리자" 이거나 해당 문서의 담당자이면 해결 할 수 있다.
