Spring Web Security

* 필터와 인터셉터 : 특정한 서블릿이나 컨트롤러의 접근에 관여한다는 점에서 유사함

- 필터 : 스프링과 무관한 서블릿 자원

- 인터셉터 : 스프링의 빈으로 관리됨. 스프링의 컨텍스트 내에 속함

 

 

인증(Authentication)과 권한 부여(Authorization - 인가)

* 인증 : '자신을 증명하는 것', 자기 스스로 무언가 자신을 증명할 만한 자료를 제시하는 것

* 권한 부여 : 남에 의해 자격이 부여됨

 

* 인증 매니저 (AuthenticationManager)

* ProviderMAnager는 인증에 대한 처리를 AuthenticaitonProvider라는 타입의 객체를 이용해 처리를 위임함

 

* AuthenticationProvider(인증 제공자) : 실제 인증 작업을 진행함

- 이때 인증된 정보에는 권한에 대한 정보를 같이 전달함 => UserDetailsService인터페이스와 관련있음 (사용자의 정보와 사용자가 가진 권한의 정보를 처리해서 반환함)

- 대부분의 경우, UserDetailsService를 구현하는 형태를 사용하는 것만으로 충분하지만, 새로운 프로토콜이나 인증 구현 방식을 직접 구현하는 경우 AuthenticationProvider 인터페이스를 직접 구현해서 사용함

 

---

로그인와 로그아웃 처리

 

* 접근 제한 설정 : security-context.xm

특정 URI에 접근할 때 인터셉터를 이용해 접근을 제한하는 설정 : <security:intercept-url> 이용

- pattern 속성 : URI의 패턴을 의미함

- access 속성 : 권한 체크 => 위의 경우 'ROLE_MEMBER'라는 권한이 있는 사용자만 접근 가능

=> /sample/member로 들어가면, 강제로 로그인 페이지로 이동함 (스프링 시큐리티가 제공하는 기본 로그인 페이지. 테스트 과정에서만 사용할만함)

 

단순 로그인 처리

스프링 시큐리티의 용어와 일반 시스템 의미와 차이가 있음

- userid : 스프링 시큐리티에서는 'username'에 해당

- User : 스프링 시큐리티에서는 인증 정보와 권한을 가진 객체 => 일반적 경우에 사용하는 사용자 정보와는 다른 의미

- 이를 구분하기 위해 시스템상 회원 정보는 MemberVO 클래스를 이용

 

* security-context.xm의 일부

- 'member'라는 계정 정보를 가진 사용자가 로그인을 할 수 있도록 함

=> PasswordEncoder가 없기 때문에 오류 발생 (스프링 시큐리티 5버전부터 반드시 사용하도록 되어있음)

- 임시 방편으로 스프링 시큐리티 5버전에 포맷팅 처리를 지정해서 패스워드 인코딩 방식을 지정할 수 있음.

만일 패스워드의 인코딩 처리 없이 사용하고 싶다면, 패스워드 앞에 '{noop}' 문자열 추가하기

=> 사용자'member'에 비밀번호'member' 라는 것을 사용하면, "ROLE_MEMBER" 라는 권한을 부여할 수 있음

 

로그아웃 확인

스프링 시큐리티를 학습하다 보면 매번 로그아웃하고 새롭게 로그인 해야 하는 상황이 발생함

이에 대한 가장 확실한 방법은 세션과 관련된 정보를 삭제하는 것

개발자 도구 => Application 탭 => Cookies 항목 => 'JSESSIONID' 세션 쿠키 JSESSIONID는 Tomcat에서 발생하는 쿠키의 이름 (WAS 마다 다른 이름을 사용함)

로그아웃은 JSESSIONID 쿠키를 강제로 삭제해서 처리함

쿠키를 삭제한 후, 로그인이 필요한 URI를 다시 호출해보면 로그인이 필요한 것을 확인할 수 있음

 

여러 권한을 가지는 사용자 설정

'sample/admin'은 'ROLE_ADMIN'과 'ROLE_MEMBER' 라는 2개의 권한을 가지도록 지정함

<security:intercept-url>은 '/sample/admin'에 대한 접근을 설정함

<security:user>에 추가된 admin 사용자 => 'ROLE_MEMBER'와 'ROLE_ADMIN'이라는 2개의 권한을 가지도록 설정함

Admin 계정을 가진 사용자는 '/sample/member'와 '/sample/admin' 모두에 접근할 수 있음

 

커스텀 로그인 페이지

스프링 시큐리티에서 기본적으로 로그인 페이지를 제공하지만, 별도의 URI를 이용해 로그인 페이지를 다시 제작해서 사용함

직접 특정한 URI를 지정할 수 있음

- login-page의 URI는 반드시 GET 방식으로 접근하는 URI를 지정함

 

CSRF(Cross-site request forgery) 공격과 토큰 

스프링 시큐리티에서 POST 방식을 이용하는 경우, 기본적으로 CSRF 토큰을 이용함

별도의 설정이 없다면, 스프링 시큐리티가 적용된 사이트의 모든 POST 방식엔 CSRF 토큰이 사용됨 => '사이트간 위조 방지'를 목적으로 특정한 값의 토큰을 사용

CSRF 공격 : '사이트간 요청 위조'. 서버에서 받아들이는 정보가 특별히 사전 조건을 검증하지 않는다는 단점을 이용한 공격 방식.

 

* 스프링 시큐리티의 CSRF 설정

일반적으로 CSRF 토큰은 세션을 통해 보관, 브라우저에서 전송된 CSRF 토큰값을 검사하는 방식으로 처리함

스프링 시큐리티는 CSRF 토큰 생성을 비활성화하거나 CSRF 토큰을 쿠키를 이용해 처리하는 등의 설정을 지원함

<security:csrf disabled="true" />