1. 스프링 시큐리티 소개

배경

2003년 후반 “스프링을 위한 아씨지 시큐리티 시스템”으로 출발. 심플한 시큐리티 구현체가 완성. 초기 사용 시작. 2004년 3월에 정식으로 출범. 몇 년 후 스프링 프레임웍의 공식적인 서브 프로젝트가 됨. 2007년 후반에 공식적으로 스프링 포트폴리오 프로젝트가 되었고, “스프링 시큐리티”로 브랜드가 변경되었다.

목적

J2EE – 기반 엔터프라이즈 소프트웨어 애플리케이션을 위한 종합적인 보안 서비스를 제공한다.

2. 스프링 시큐리티 사용하기

스프링 시큐리티는 강력하면서도 쉽다. 게다가 단 몇 십 줄의 코드만으로도 대형 웹 서비스사와 비슷한 수준의 보안을 유지할 수 있다는 장점이 있다.

보안이란?

위의 두 단어는 스프링 시큐리티 뿐만이 아니라 일반 보안에서도 핵심 축이다. 먼저 인증의 종류부터 알아보자. 인증에는 여러 가지 종류가 있지만 보통 3가지로 분류하곤 한다.

◎ 크리덴셜(Credential: 자격) 기반 인증

- 웹에서 사용하는 대부분의 인증 방식은 크리덴셜 기반의 인증 방식이다. 즉 권한을 부여 받는데 1차례의 인증과정이 필요하며 대개 사용자명과 비밀번호를 입력 받아 입력한 비밀번호가 저장된 비밀번호와 일치하는지 확인한다. 일반적으로 스프링 시큐리티에서는 아이디를 프린시플(principle), 비밀번호를 크리덴셜(credential)이라고 부르기도 한다.

◎ 이중 인증(Two-factor authentication)

- 한번에 2가지 방식으로 인증을 받는 것을 말한다. 예를 들어 금융, 은행 웹 어플리케이션을 이용해 온라인 거래를 할 경우 로그인과 보안 인증서, 2가지 방법으로 인증을 받곤 한다. 별 것 아닌 것 같지만 Authentication이 하나 추가됨으로써 프로그래밍 적으로 변화해야 할 부분은 상당히 광범위해진다.

◎ 물리적인 인증

- 이 부분은 웹의 영역을 벗어난 것이지만 가장 효과적인 보안 수단 중에 하나이다. 예를 들어 컴퓨터를 킬 때 지문을 인식 받는다거나 키를 삽입해야 하는 것들 말이다. 앞으로 스프링 시큐리티를 이용해 구현해나갈 인증(Authentication)은 바로 크리덴셜(Credential) 인증이다.

권한부여에는 크게 2가지로 나뉠 수 있다.

◎ 부여된 권한(Granted Autority)

- 적절한 절차로 사용자가 인증되었다면 권한을 부여(Granted Authority)해야 할 것이다. 회원가입 등을 통해 반영구적인 권한이 부여되었다면 이 회원에게 부여된 권한을 어딘가에 저장해야 하며, 만약 해당 사용자가 로그인을 했는데 메인 페이지로 넘어갈 수 없다면 권한부여에 문제가 있는 것이다.

◎ 리소스의 권한(Intercept)

- 사용자의 권한만 있다고 보안이 제대로 동작 할 리는 없다. 보안이란 본래 권한이 없는 자들이 원천적으로 리소스에 접근할 수 없도록 막아내는 것이기 때문이다. 그런 의미에서 적절한 권한을 가진자만 해당 자원에 접근할 수 있도록 자원의 외부 요청을 원천적으로 가로채는 것(Intercept)이 웹 보안, 그 중 권한부여(Authorization)의 핵심 원칙이라 할 수 있겠다.

스프링 시큐리티는 쉽고 편리하다는 장점도 있지만 이런 보안 개념이 없는 자가 보안이 필요한 쇼핑몰이나 주요 웹사이트를 설계했다고 가정했을 때 발생할 막대한 피해들을 방어할 수 있는 최선의 선택이다. 스프링 시큐리티는 이런 과제들을 거의 10년 가까이 연구하며 발전해온 뛰어난 보안 프레임워크라는 점을 볼 때 스프링 시큐리티는 선택이 아니라 필수라고도 할 수 있다.

리소스의 권한(Intercept)

아무리 서버 성능이 좋고 직원이 많더라도 가지고 있는 모든 리소스에 일일이 권한을 설정할 수는 없는 노릇이다. 대신에 @MVC에서 본 것처럼 DispatcherServlet처럼 멋지게 클라이언트의 요청을 가로챌 수만 있다면 간단히 문제를 해결할 수 있을 것이다.

먼저 기존의 제작된 프로젝트에 다음과 같이 web.xml에 DelegatingFilterProxy를 등록한다.

여기서 주의할 점은 <filter-name>의 값이 반드시 springSecurityFilterChain이어야 한다는 점이다. 왜 꼭 이름을 pringSecurityFilterChain으로 지어야 하냐면 DelegatingFilterProxy 클래스는 setTargetBeanName(String)이라는 메서드를 갖고 있는데 이 메서드는 실제 요청을 처리할 필터를 주입 받는다. 만약 이 메서드를 통해 구현할 필터 빈을 주입 받지 못한다면 DelegatingFilterProxy 클래스는 기본값으로 <filter-name>의 값과 동일한 빈이 스프링 컨텍스트에 존재하는지를 검색하게 된다.

그러나 곧 알게 되겠지만 DelegatingFilterProxy 클래스가 springSecurityFilterChain이란 빈이 필요하다고 직접 빈을 만들어줄 필요는 없다. 왜냐하면 springSecurityFilterChain은 스프링 시큐리티의 inner bean이기 때문에 자동으로 생성되기 때문이다.

이런 관점에서 본다면 DelegatingFilterProxy는 굳이 스프링 시큐리티에서만 사용할 게 아니라 다른 목적의 필터 체인으로도 충분히 사용될 수 있는 확장성이 존재한다. 아마 스프링 제작진들도 이 클래스가 스프링 시큐리티에서 탄생했지만 역할의 중요성을 인식해 시큐리티 내부 패키지에 위치시키지 않고 org.springframework.web.filter에 등록시킨 것 같다.

3. 자료 출처

• - 도서 : 스프링 시큐리티3
• - Springmvc.egloos.com 블로그