[Spring Security] 403 Error & authority(권한), Role(역할) 차이

 

403 그래.. 권한 문제라는건 알겠어..
 권한부여가 왜 안된걸까..?

 

 

아래 사진을 보면 SecurityFilterChain의 Bean을 주입하는 곳에서의 설정과 dummy user id를 만들 때 권한부여, Test코드에서 권한부여(아래 사진으로는 roles) 모두 권한을 주입하고 확인하는 코드를 볼 수 있다.
spring security 403 권한문제 관련 블로그들도 찾아보았고 분명 권한을 주었지만 관리자 페이지에 접근하는 테스트코드에서 권한이 없어서 403 에러가 뜨는것을 볼 수 있었다. 

 

 

test result

securityConfig file

test file

MockHttpServletRequest의 Session Attrs

csrf 문제는 아님. 잘 들어가 있음

 

 

csrf, role_admin까지 확인하고 403페이지까지 나오니 권한 문제란 것까지는 좁혀졌다. 하지만 도저히 디버깅을 어떻게 해야할지 방법을 찾지 못하고 시간을 너무 소비했기에 하루를 넘겼다. 다음날(지금)에 보니 'roles가 권한이라고는 하지만 securitychanin에 적혀있는 authority와 같다고 볼 수 있을까?' 라는 생각에 role과 authority가 있는곳에 서로 authority와 role을 타이핑 해보니 관련된 메서드들이 나오는 것이었다. 등골이 쎄함과 동시에 기분이 좋아졌다.

roles도 있고 authorities도 있네?

여기도 role과 authority 있네?

여기에서 spring security의 authority와 role의 정의에 대해  짚고 넘어가야할 부분이라 공식문서를 찾아보았다.

https://docs.spring.io/spring-security/site/docs/5.2.11.RELEASE/reference/html/authorization.html

11. Authorization

ㄴ> hasAnyRole 혹은 hasRole의 prefix에 'ROLE_'로 시작하지 않아도 자동으로 붙여서 체크한다고 적혀있다.

https://www.baeldung.com/spring-security-granted-authority-vs-role

벨덩 url은  authority vs role. 가슴이 웅장해졌다.

 

해당 문서에서 찾은 결론을 정리하자면 role, authority 모두 권한에 관한 것이고 동작법에 큰 차이가 없다. 하지만 role은  사용시에 접두사로 "ROLE"이라는 문자열이 붙는다(ROLE_). 그렇기 때문에 hasRole인 경우에는 "ROLE_ADMIN"(ADMIN만해도 'ROLE_' 이 prefix로 붙긴함), hasAuthority인 경우엔 "ADMIN"으로 권한 유무를 파악해야 하는 것이다. 

 

위의  authority와 role의 논리적 개념을 조금 더 설명하자면 하지만 '의미를 부여하는 방법'에 있어서 차이가 있다고 나온다.

The core difference between these two is the semantics we attach to how we use the feature.
For the framework, the difference is minimal 
– and it basically deals with these in exactly the same way.

 

더 자세히 살펴보면

Now that we’ve seen how the framework uses the role concept, let’s also quickly discuss an alternative 
 – and that is using roles as containers of authorities/privileges.
 (역할(role)을 권한(authority)의 컨테이너로 사용한다 -> 역할이 authority의 집합체라고 해석 가능)

This is a higher level approach to roles 
 – making them a more business-facing concept rather than an implementation-centric one.
(여긴 대놓고 나온다. roles가 상위 레벨의 개념이고 구현(detail)보단 비즈니스(상위개념)개념에 가깝다)

The Spring Security framework doesn’t give any guidance in terms of 
 how we should use the concept, so the choice is entirely implementation specific.
 (spring scurity쪽에서 크게 제약사항을 만들지 않았고, 비즈니스에 따라 다르게 사용할 수 있다.)

 

즉 roles, authority 모두 권한에 관련된 건 맞지만 detail의 범위를 어느 기준에 두느냐에 따라 role과 authority로 구별해서 사용할 수 있다이다. 특정 세부적인 기능에 대해서 권한 유무로 접근을 제한 할 때에는 authority, 전체적인 그룹별로 권한을 부여할 때에는 role등으로 논리적 개념으로 나누어서 사용해도 좋을 것 같습니다.

 

이렇게 spring security의 role과 authority의 약간의 사용법에 대한 차이와 논리적인 차이에 대해서 알 수 있었다. 현업에서도 이런 흐름으로 문제를 자주 해결 하기도 하고 이런 방식이 나쁜지는 잘 모르겠지만 'security 강의를 구매해서 처음부터 개념을 잡아가며 들었으면 이런 문제를 안겪었을 수도 있으려나?' 라는 생각도 든다.