이번 강의에서는
이전 강의에서 생성한 역할을 사용하여
웹 애플리케이션 내에서 인가를 강제하는 것을
시도해보겠습니다
이 슬라이드에서 볼 수 있듯이
역할을 활용하여 인가를 강제하기 위해서는
세 가지의 메소드가 필요합니다
이 세 가지 메소드 중 아무거나 사용할 수 있습니다
첫 번째 메소드는 hasRole()로 하나의 역할을
하나의 인풋으로 받아들입니다
해당 역할을 가진 최종 사용자만이
hasRole() 메소드를 사용하는
특정 API에 액세스할 수 있지만
특정 API 경로가 주어진 역할 목록 중
어떤 역할이든 액세스할 수 있어야 하는 경우
hasAnyRole()을
사용할 수 있습니다
이것은 hasAuthority()나 hasAnyAuthority()와 매우 유사합니다
여기서는 인가를 강제하기 위해 역할을 활용하므로
hasRole() 혹은 hasAnyRole()를 활용해야 합니다
마지막으로 사용할 수 있는 메소드는
권한을 이야기 할 때 살펴보았던
access() 메소드입니다
따라서 이는 역할과
SpEL를 사용하여
인가 규칙을 강제할 수 있는
동일한 메소드입니다
SpEL를 사용하면
OR 또는 NOT 같은 조건도 가능합니다
여기서 짚고 가고 싶은
한 가지 중요한 정보는
우리의 데이터베이스 내에 모든 역할을 위한
접두사 ROLE_ 을 유지하고 있다는 겁니다
그러나 hasRole()
hasAnyRole(0 또는 access() 메소드를 사용하려 할 때
접두사를 언급해서는 안됩니다
그 접두사 값을 지정하지 않으면
Spring Security 프레임워크가 내부적으로
이 hasRole() 또는 hasAnyRole() 메소드를
호출할 때
해당 접두사 값을 추가합니다
이것이 바로 프로젝트 구성에서
이같은 메소드를 사용할 때
수동으로 그 접두사 값을 지정할 필요가 없는 이유입니다
이제 이 메소드를 호출하는 방법에 대해 살펴봅시다
여기서 볼 수 있듯이
hasAuthority()나 hasAnyAuthority()와 매우 유사합니다
우리는 또한 requestMatchers 메소드의 도움을 통해
보안 요구사항을 정의 내린 후
이러한 hasRole() 또는 hasAnyRole() 메소드를 호출할 수 있습니다
이 메소드를 사용하려면
역할 정보를 전달해야 합니다
따라서 여기서 저는 접두사의 값을 전달하는 게 아닌
사용자와 관리자를 정의 내리는 것입니다
이것이 바로 지난 강의에서 데이터베이스 내에
생성했던 역할들입니다
이렇게 하면 Spring Security 프레임워크 내에서
역할을 사용하여 권한을 구성할 수 있습니다
여기까지 이해가 되셨을 거라 생각합니다
다음 강의에서는
우리의 웹 애플리케이션 내에서 빠르게 이것을 실행해보고
모든게 제대로 작동하는 지 확인해 보고자 합니다
감사합니다 다음 강의에서 뵙겠습니다 수고하셨습니다