[Spring] Spring Security

1장 스프링 시큐리티란? : http://egloos.zum.com/springmvc/v/504862

2장 Intercept와 Granted Authority : http://springmvc.egloos.com/506465

3장 데이터베이스로 이동하는 Authentication 정보 : http://springmvc.egloos.com/516241

4장 JdbcDaoImpl의 커스터마이징 : http://springmvc.egloos.com/518902

5장 스프링 시큐리티에서의 비밀번호 암호화 : http://springmvc.egloos.com/520257

스프링 시큐리티 설명

Spring Security

: 매우 지능적이며 대부분 간단한 선언만으로 작동. 대량의 코드를 손쉽게 절약해줌, 강력하면서도 손쉬움

보안이란

: 본래 권한이 없는 자들이 원천적으로 리소스에 접근할 수 없도록 막아내는 것.

Authentication(인증)   ->    Authorization(권한부여)

인증 종류

1. 크리덴셜(Credential : 자격) 기반 인증 : 웹에서 대부분 사용하는 인증, 1차례 인증과정이 필요, 사용자명과 비번을 입력한 후 어딘가에 저장된 DB에서 일치하는지 여부를 확인한다. 스프링 시큐리티에서는 아이디를 프린시플(principle), 비밀번호를 크리덴셜(credential)이라고 부름. 스프링 시큐리티에서 사용

2. 이중 인증(Two-factor authentication) : 한번에 2차례 인증을 받는 것. 예) 금융, 은행 웹어플리케이션 거래 시 로그인과 보안 인증서, 2가지 방법으로 인증 받음

3. 물리적 인증 : 웹의 영역을 벗어남. 가장 효과적인 보안 수단 중 하나. 지문 인식 또는 키를 삽입

권한부여(Authorization) 종류

1. 부여된 권한(Granted Autority) : 적절한 절차로 사용자 인증 되면 권한 부여를 함. 회원가입 등으로 반영구적인 권한이 부여됨. 로그인 시 메인페이지로 넘어갈 수 없다면 권한부여에 문제가 있음.

2. 리소스의 권한(Intercept) : 적절한 권한을 가진자만 해당 자원에 접근할 수 있도록 자원의 외부 요청을 원척적으로 가로채는 것(Intercept)이 웹보안. 권한부여의 핵심 원칙

리소스의 권한(Intercept) - Authentication(인증)의 영역에 포함

: 보안에서 리소스에 접근권한을 설정하는 것이 바로 Intercept 방식으로 작동하기 있기 때문. 스프링 시큐리티는 스프링 커뮤니티에 합류하기 전까지 Acegi라는 이름의 프레임워크였음. 스프링 시큐리티는 DelegatingFilterProxy 클래스를 사용함.

시큐리티 설정

pom.xml에 라이브러리를 추가함

1) Spring-security-core

2) Spring-security-web

3) Spring-security-config

4) Spring-security-taglibs

5) Spring-security-acl

web.xml에서 DelegatingFilterProxy를 등록할 때 filter-name 값을 반드시 springSecurityFilterChain이어야 한다. 메서드를 통해 구현할 필터빈을 주입받지 못하면 DelegatingFilterProxy 클래스는 기본값으로 <filter-name>의 값과 동일한 빈이 스프링 컨텍스트에 존재하는 지를 검색하게됨. inner been이기 때문에 자동으로 생성됨

서로 겹치는 URL이 요청으로 들어오면 필티가 우선순위가 된다. 필터는 프록시 패턴처럼 서블릿을 샌드위치 해버린다. 보안에 대해서 따로 관리해주는 파일을 만드는 것이 좋다. security-context.xml이란 파일로 만든다. web.xml에 등록한다.

security-context.xml을 열어 네임스페이스를 설정한다. 

<http auto-config="true">
<intercept-url pattern="/-" access="ROLE_USER" />
</http>

스프링 시큐리티는 Authorization(권한부여)에 관한 대부분의 설정이 <http>요소에 위치해 있으며 설정 가능한 모든 요소에 디폴트 값이 존재한다. <intercept-url>은 DelegatingFilterProxy에서 가로챈 요청을 좀 더 세부적으로 나눠주며(pattern) 접근할 수 있는 권한으 설정(access)한다.

부여된 권한(Granted Authority) - Authorization(권한부여)의 영역에 포함

<authorization-manager> : 권한 부여의 영역을 분할하기 위해 따로 사용함.

<user name="guest" password="guest" authorities="ROLE_USER"/> 가급적 'ROLE_'이란 문자열 사용 권장, RoleVoter가 부여된 권한을 검사하는데 문자열이 ROLE_이란 접두어로 시작하는지 검사하기 때문

org.springframework.security.access.AccessDecisionVoter의 int 상수

ACCESS_GRANTED(접근 승인, 값=1) : RoleVoter가 접근 결정자에게 접근을 승인할 것을 요청.
ACCESS_ABSTAIN(접근 보류, 값=0 : RoleVoter가 접근 결정자에게 접근을 보류할 것을 요청.
ACCESS_DENIED(접근 거부, 값=-1) : RoleVoter가 접근 결정자에게 접근을 거부할 것을 요청.

부여할 권한의 이름 설정이 중요한 역할을 담당, <intercept-url>에서 선별한 자원에 사용자가 접근할 수 있게 하려면 <intercept-url access>의 값과 <user authorization>의 값이 서로 일치하게 만들어야 한다.

사용자가 많게 되면 <jdbc-user-service>를 이용해 권한 부여의 대부분을 DB로 이전시켜야한다.

스프링 시큐리티의 표현식 언어

: 스프링 표현식 언어를 사용하면 RoleVoter에서 수행하지 않는 보안설정을 표현식을 통해 추가할 수 있다.

<http auto-config="true" use-expressions="true">
<intercept-url pattern="/-" access="hasRole('ROLE_USER')"/>
</http>

intercept access에서만 설정이 가능

: hasIpAddress(ip) - 접근자의 IP주소가 매칭하는지 확인

: hasRole(role) - 역할이 부여된 권한(Granted Authority)와 일치하는지 확인

: hasAnyRole(role) - 부여된 역할 중 일치하는 항목이 있는지 확인 예) - access = "hasAnyRole('ROLE_USER', 'ROLE_ADMIN')"

: permitAll - 모든 접근자를 항상 승인

: denyAll - 모든 사용자의 접근을 거부

: anonymous - 사용자가 익명 사용자인지 확인

: authenticated - 인증된 사용자인지 확인

: rememberMe - 사용자가 remember me를 사용해 인증했는지 확인

: fullyAuthenticated - 사용자가 모든 크리덴셜을 갖춘 상태에서 인증했는지 확인

로그인 페이지 커스터마이징

<form-login> 요소를 이용하면 손쉽게 로그인 페이지를 커스터마이징 할 수 있음

<form-login login-page="/login" username-parameter="username" password-parameter="password" login-processing-url="/authentication" />

: login-page - 로그인이 요청될 시에 이동할 URL을 설정

: username-parameter - 로그인 아이디 파라미터명 즉 name필드 값을 설정

: password-parameter - 비밀번호의 파라미터 명을 설정

: login-processing-url - 폼에서 전송할 URL 값을 설정(action=login-processing-url)

주의! 로그인 URL 인터셉터를 모든 리소스를 차단하는 인터셉터의 위쪽으로 배치시켜야 한다. 그렇지 않으면 리디렉션 순환 오류로 정상적인 로그인 창이 뜨지 않음.

로그아웃 커스터마이징

<http>에 요소를 추가하여 로그아웃 경로를 커스터마이징 할 수 있음

<logout invalidate-session="true" logout-url="/unAuthentication" logout-success-url="/" />

invalidata-session : 세션을 모두 무효로 할 것인지를 사용자에게 묻는다.

logout-url : 로그아웃 경로를 설정한다.

logout-seccess-url : 로그아웃이 성공한 뒤에 이동한 경로를 설정한다.

MySQL로 Authentication 구현하기

상용 서비스로 오픈하기 위해서 인증 자료의 DB이전은 필수 중 하나. 해당 사용자의 권한과 세부정보들을 모두 DB에 저장하게 하고 스프링 시큐리티는 그 정보들을 쿼리를 이용해 가져오는 방식으로 바꾼다.

Remember me

: 사용자 세션이 종료된 후에도 자동으로 로그인할 수 있는 기능, 추가적인 쿠키를 저장. 그 기간을 정하면 로그인하지 않고도 인증할 수 있음, 쿠키는 username/expirationTime/password/key와 같은 MD5 hash로 인코딩한 정보를 포함함.

global method security

: @Secured 어노테이션을 사용하기 위해서 servlet-context.xml에 설정한다. security-xontext.xml와 servlet-context.xml 서로간의 객체를 공유를 못하기 때문에 global-method-security 설정이 컨트롤러에 선언된 어노테이션을 못 불러온거임.

* .xml로 설정 대신 class로 설정하는 이유 ? 컴파일 시 에러 체크가 가능하기 때문(티몬, 쿠팡에서 사용함)