Authentication : 인증, Authorization : 권한부여 (서로 다른 단어!!!!!)
인증의 종류
1. 크리덴셜(Credential:자격) 기반 인증 - 웹에서 사용하는 대부분의인증 방식은 크리덴션 기반의 인증 방식. 즉 권한을 부여받는데 1차례의 인증과정이 필요하며 대개 사용자명과 비밀번호를 입력받아 입력한 비밀번호가 저장된 비밀번호와 일치하는지 확인합니다. 일반적으로 스프링 시큐리티에서는 아이디를 프린시플(principle), 비밀번호를 크리덴셜(credential)이라고 부른다.(스프링 시큐리티를 이용해 구현해나갈 인증(Authentication))
2. 이중 인증(Two-factor authentication) - 한번에 2가지 방식으로 인증을 받는 것. 예를 들어 금융, 은행 웹어플리케이션을 이용해 온라인 거래를 하실 때에는 로그인과 보안 인증서, 2가지 방법으로 인증을 받는다.
3. 물리적인 인증 - 웹의 영역을 벗어난 것이지만 가장 효과적인 보안 수단 중에 하나. 지문인식 혹은 키 삽입 방법.
권한부여(Authorization)
1. 부여된 권한(Granted Autority) - 적절한 절차로 사용자가 인증되었다면 권한을 부여(Granted Authority)해야 한다. 회원가입 등을 통해 반영구적인 권한이 부여됬다면 우리는 이 회원에게 부여된 권한을 어딘가에 저장해야 한다. 만약 해당 사용자가 로그인을 했는데 메인 페이지로 넘어갈 수 없다면 권한부여에 문제가 있다는 것.
2. 리소스의 권한(Intercept) - 사용자의 권한만 있다고 보안이 제대로 동작할리는 없다. 보안이란 본래 권한이 없는 자들이 원천적으로 리소스에 접근할 수 없도록 막아내는 것이기 때문입니다. 그런 의미에서 적절한 권한을 가진자만 해당 자원에 접근할 수 있도록 자원의 외부요청을 원천적으로 가로채는 것(Intercept)이 웹보안, 그 중 권한부여(Authorization)의 핵심 원칙이라 할 수 있겠습니다.
어떤 방식으로 권한을 부여할지, 해당 리소스에 어떻게 권한수준을 부여하고, 인증받은 정보를 어떻게 지속적으로 유지할 수 있을지에 대한 여러 이슈들을 스프링 시큐리티는 10년가까이 연구하며 발전한 보안 프레임워크이고 보안 개념이 없는 자가 보안이 필요한 쇼핑몰이나 주요 웹사이트를 설계했다고 가정했을 때 발생할 막대한 피해들을 방어할 수 있는 최선의 선택이라고 한다….
리소스의 권한(Intercept)
보안에서 리소스에 접근권한을 설정하는 것이 바로 Intercept 방식으로 작동하고 있다.
아무리 서버 성능이 좋고 직원이 많더라도 가지고 있는 모든 리소스에 일일이 권한을 설정할 수는 없는 노릇이다. 대신에 @MVC에서 보았듯 DispatcherServlet처럼 클라이언트의 요청을 가로챌 수만 있다면 간단히 문제를 해결할 수 있을 것이다.
스프링 시큐리티는 @MVC의 DispatcherServlet이나 AOP를 이용해 프록시를 생성하지 않고 아주 오래 전부터 사용해온 고유의 DelegatingFilterProxy 클래스를 사용.
web.xml에 DelegatingFilterProxy를 등록
여기서 주의할 점은 <filter-name>의 값이 반드시 springSecurityFilterChain이어야 한다는 점입니다. 왜 꼭 이름을 springSecurityFilterChain으로 지어야 하냐면 DelegatingFilterProxy 클래스는 setTargetBeanName(String)이라는 메서드를 갖고 있는데 이 메서드는 실제 요청을 처리할 필터를 주입받습니다. 만약 이 메서드를 통해 구현할 필터빈을 주입받지 못한다면 DelegatingFilterProxy 클래스는 기본값으로 <filter-name>의 값과 동일한 빈이 스프링 컨텍스트에 존재하는지를 검색하게 됩니다.
security-context.xml의 네임스페이스는 아래와 같이 설정하였다.(인강이랑 다른점)
이 네임스페이스는 security를 기본 xmlns로 선택하고 있는 컨텍스트 네임스페이스이다.
<beans:beans>로 된 점을 주의
<http auto-config="true"> : 스프링 시큐리티는 기본적으로 Ahthorization(권한 부여)에 관한 대부분의 설정이 요소에 위치해 있으며 설정 가능한 모든 요소에 디폴트 값이 존재한다. 그러므로 요소의 auto-config 속성을 true로 잡아줌으로써 우리는 모든 디폴트 속성값으로 서버를 설정한 것.
<intercept-url> : DelegatingFilterProxy에서 가로챈 요청을 좀 더 세부적으로 나눠주며(pattern) 접근할 수 있는 권한을 설정(access)합니다.
ROLE_USER와 같이 부여된 권한(Granted Authority) 설정은 어디서 하게 되는 걸까? : 리소스의 권한(Intercept)은 Authentication(인증)의 영역에 포함됩니다. 우리가 무언가의 인증을 받은 후에 리소스에 접근할 권한을 얻게 되므로 리소스의 권한은 인증작업에 일부가 되는 셈이죠. 그렇다면 부여된 권한(Granted Authority)는 어디에 속할까요? 바로 Authorization(권한부여)에 속하게 됩니다. 권한을 부여하려면 먼저 권한부터 설정되있어야 하며 궁극적으로 설정된 권한을 유저에게 부여해줘야 하기 때문입니다.
그러므로 <http>요소는 Authentication(인증)의 범주에 속해있으며 스프링 시큐리티는 Authorization(권한부여)의 영역을 분할하기 위해 <authorization-manager>란 요소를 따로 사용하고 있습니다.출처:부여된 권한
<intercept-url>은 DelegatingFilterProxy에서 가로챈 요청을 좀 더 세부적으로 나눠주며(pattern) 접근할 수 있는 권한을 설정(access)한다.
먼저 인증받을 사용자의 아이디와 비밀번호를 입력한 뒤에 해당 사용자에게 권한(ROLEUSER)를 부여한다. 가급적 **‘ROLE’** 이란 문자열로 시작해야 한다. 왜냐하면 스프링 시큐리티는 RoleVoter라고 부여된 권한(Granted Authority)을 검사하는 클래스를 가지고 있는데 이 검사자가 문자열이 ROLE이란 접두어로 시작하는 지를 검사하기 때문. 만약 ROLE이란 접두어로 시작하지 않는다면 시큐리티는 접근 보류(ACCESS_ABSTAIN)라는 결론을 짓게 된다.
보안관련 taglib를 추가한 뒤 로그인화면에 적용하기.
[1] pom.xml에 아래와 같이 taglib를 추가할 수 있다. (프로젝트 스프링프레임워크 버전이 3.2이므로 똑같이 3.2로 맞춰서 add시킴.)
[2] 그리고 login.jsp 파일에 taglib 를 추가하고 아래의 소스코드를 넣어 로그인이 되도록한다.