Spring Security #2 다양한 사용법 - 익명사용자, 세션 제어, 예외처리

 

스프링 시큐리티 - Spring Boot 기반으로 개발하는 Spring Security - 인프런 | 강의

 

아래의 보안 기능들은 직접 구현하고자하면 상당히 귀찮다.

스프링 시큐리티에서는 간단한 설정 값을 통해 다양한 기능을 사용할 수 있다.

💭 익명 사용자 필터 (AnonymousAuthenticationFilter)

이름 그대로 현재 사용자가 인증(로그인)이 되어있는지, 아닌지를 판단하는 필터이다.

스프링 시큐리티에서는 익명 사용자라고 할지라도, 인증개체를 null로 처리하지 않고 [익명 사용자 토큰]을 생성한다.

인증객체가 null이라면 SecurityContext만으로는 익명사용자가 있는지, 아예 접속을 하지 않은건지 구분할 수 없다.

익명사용자 토큰을 통해 인증 여부에 따른 다른 화면을 구현할 때, 아래와 같은 메서드를 사용해서 쉽게 만들 수 있다.

• isAnonymous() - 익명 사용자인가? (페이지에 로그인 메뉴 표시)
• isAuthenticated() - 로그인된 사용자인가? (페이지 로그아웃 메뉴 표시)

물론 첫 접속에서 익명 사용자 토큰(인증객체)가 생성되었다면 이후 만료되기 전까지는 해당필터는 동작하지 않는다.

인증객체가 null일때만 AnonymousAuthenticationFilter가 동작한다.

 

 

💭 세션 관리 필터 (SessionManagementFilter)

📑 동시 세션 제어 (동일계정 중복접속)

한 계정으로 여러 컴퓨터에서 접속하는 경우, 세션은 여러 개가 생성될 수 있다.

이를 스프링 시큐리티에서는 http.sessionManagement()를 이용해서 간단하게 처리할 수 있다.

 

maxSessionPreventsLogin(true)를 하게되면 아래 그림의 [2. 현재사용자 인증실패] 처럼 동작한다.

한 계정으로 여러 곳에서 접속했을 때 어떻게 처리할지 정할 수 있다. default값은 [1. 세션만료]이다.

 

이는 ConcurrentSessionFilter 를 통해 동작하게된다. 필터의 동작은 앞 글에서 많이 다뤘으므로, 궁금하면 구글 검색하자

2021.11.22 - [🌱Backend/Spring Security] - Spring Security #1 기본동작 이해하기

 

 

 

📑 세션 고정 보호 (세션 주입 공격, sessionFixation)

보통 웹 서비스는 로그아웃 후 바로 다시 로그인을 하더라도 기존의 JSESSIONID를 재사용하지 않고 새로 발급한다.

스프링 시큐리티도 마찬가지로 세션에 기존의 인증개체가 있더라도 로그인을 요청하면 JSESSIONID는 새로 발급한다. 

기존의 값을 이용해도 될거같은데, 번거롭게 로그인 요청마다 새롭게 발급하는 이유는 무엇일까?

 

이는 세션고정공격 (SessionFixation)으로 인한 세션 하이재킹(세션 탈취)를 막기 위함이다.

만약 아래와 같이 공격자가 먼저 로그인을 한 후, 사용자 컴퓨터에 JSESSIONID 쿠키를 심어놓았다고 가정해보자. 

<!-- script 를 이용한 세션 주입 -->
<script>document.cookie="jsessionid=함정세션ID";</script>

<!-- meta 태그를 이용한 세션 주입 -->
<meta http-equiv="Set-Cookie" content="jsessionid=함정세션ID">

이를 세션 고정 공격을 통한 세션 하이재킹이라고 한다.

이를 세션 고정 공격이라고 한다.

당연히 스프링 시큐리티에서는 세션고정보호(changeSessionId)가 기본적용되어있으며, 이는 설정에서 변경할 수 있다.

newSession()은 이전 세션에서 설정한 인증개체의 속성 값도 초기화한다. (인증개체 clear)

 

물론 이를 변경 할 일은 거의 없다. 사용하지 않더라도 알고는 있도록 하자.

😒 : 원래 웹은 JSESSIONID를 매번 새롭게 발급해주는건가요?
🙄 : 어...잘모르겠는데 돌려보니까 그렇더라구요. 아마 그렇지 않을까요? (???)

 

 

📑 세션 정책 변경

웹 서비스에 따라 따로 사용자 인증이 필요 없는 경우, 세션이 필요없을 수도 있다.

또는 JWT토큰 등을 사용하면 서버에 아예 세션을 생성하지 않기 때문에 세션을 만들 필요가 없다.

이럴 때는 스프링 시큐리티의 세션 정책(sessionManagement().SessionCreationPolicy)을 통해 쉽게 설정할 수 있다.

Never는 생성은 안하지만, 사용은 한다. [JWT 토큰]처럼 세션이 아예 필요없다면 Stateless를 사용하자.

 

 

📑 정리 (SessionManagementFilter)

• 기본적인 세션관리
• 동시적 세션 제어 
• 세션 고정 보호 (sessionFixation)
• 세션 생성 정책 (Always, If_Required, Never, Stateless)

참고로 이 과정에서는 SessionManagementFilter와 함께 ConcurrentSessionFilter도 사용된다.

 

 

📑 ConcurrentSessionFilter, 전체 동작흐름

ConcurrentSessionFilter는 매 요청마다 현재 사용자의 세션 만료 상태를 확인하며, 만료인 경우 즉시 처리를 한다.

• 로그아웃에 필요한 처리
• 오류페이지 응답 (필터체인으로 넘기지 않고 ConcurrentSessionFilter 에서 즉시 응답)

 

그래서 앞에서 배웠던 UsernamePasswordAuthenticationFilter, SessionManagementFilter와 함께 보면 아래 그림과 같다.

설정값을 통해 SessionManagementFilter 안에 있는 Strategy 의 구현체를 쉽게 바꿀 수 있다.

 

 

💭 인가 API

인증(Authentication)은 '내가 누구인지' 확인하는 작업, 로그인을 의미한다.

인가(Authorization)는 '내가 누구인지는 알지만, 권한이 있는지 확인하는' 작업이다.

 

스프링 시큐리티는 인가, 즉 접근 권한 설정을 선언적 방식과 동적 방식으로 제공해준다.

스프링 시큐리티는 특정 메서드에도 접근 권한을 설정해줄 수 있다.

 

 

📑 사용자 생성 및 권한(Role) 부여

configure 메서드를 이용해서 테스트용 사용자를 쉽게 만들 수 있다.

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
    // 물론 테스트 용도로 사용하는거지, 실제 사용은 동적으로 DB와 연동해서 계정을 생성한다.
        auth.inMemoryAuthentication().withUser("user").password("{noop}1111").roles("USER");
        auth.inMemoryAuthentication().withUser("system").password("{noop}1111").roles("SYS");
        auth.inMemoryAuthentication().withUser("admin").password("{noop}1111").roles("ADMIN");
    }

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.authorizeRequests() // 인가, 권한이 필요한 요청 URL
            .antMatchers("/user").hasRole("USER") // user만 접근가능
            .antMatchers("/admin/pay").hasRole("ADMIN") // admin만 접근가능
            .antMatchers("/admin/**").access("hasRole('ADMIN') or hasRole('SYS')") // system,admin만
            .anyRequest().authenticated(); // 그 외 모든 요청은 인증만 필요.

        http.formLogin();
    }
}

URL 설정은 구체적인 경로를 먼저 작성해야한다.

참고로 포함관계 (System은 Admin과 User권한을 포함)라면 아래와 같이 작성해주어야한다.

@Override
protected void configure(AuthenticationManagerBuilder auth) throws Exception {
    auth.inMemoryAuthentication().withUser("user").password("{noop}1111").roles("USER");
    auth.inMemoryAuthentication().withUser("system").password("{noop}1111").roles("USER","SYS");
    auth.inMemoryAuthentication().withUser("admin").password("{noop}1111").roles("ADMIN","SYS","USER");
}

다만 스프링 시큐리티에는 권한 계층 기능이 있어서 이렇게 일일이 지정하지 않아도 포함관계를 쉽게 설정할 수 있다.

 

 

📑 URL 권한 설정(인가)

참고로 권한 설정을 하는 메서드는 아래와 같다.

메소드	동작
authenticated()	인증된 사용자의 접근을 허용
fullyAuthenticated()	인증된 사용자의 접근을 허용, rememberMe 인증 제외
permitAll()	무조건 접근을 허용 (모두가 접근 가능)
denyAll()	무조건 접근을 허용하지 않음
anonymous()	익명사용자의 접근을 허용 (* 주의 * 인증된 USER는 접근할 수 없음)
rememberMe()	기억하기를 통해 인증된 사용자의 접근을 허용
access(String)	주어진 SpEL (Spring Exp Lang) 표현식의 평가 결과가 true이면 접근을 허용
hasRole(String)	사용자가 주어진 역할이 있다면 접근을 허용 (User)
hasAuthority(String)	사용자가 주어진 권한이 있다면 (Role User)
hasAnyRole(String...)	사용자가 주어진 권한이 있다면 접근을 허용
hasAnyAuthority(String...)	사용자가 주어진 권한 중 어떤 것이라도 있다면 접근을 허용
hasIpAddress(String)	주어진 IP로부터 요청이 왔다면 접근을 허용

 

 

💭 인증,인가 예외처리 - ExceptionTranslationFilter

참고로 스프링 시큐리티의 마지막 필터 체인은 항상 FilterSecurityInterceptor 필터로 끝난다.

이 필터 앞에 위치하는게 ExceptionTranslationFilter인데, 코드를 살펴보면 사용자 요청을 받을 때

try-catch로 FilterSecurityInterceptor를 감싸고 있다. 즉 예외처리를 여기서 담당한다.

이 필터 역시 간단하게 사용할 수 있다.

• AuthenticationException
  1. AuthenticationEntryPoint를 호출한다. (로그인 페이지로 이동, 401 오류코드 전달 등을 담당)
  2. 인증 예외가 발생하기 전의 요청 정보를 저장한다.
  ➡ RequestCache - 사용자의 이전 요청정보를 세션에 저장하고, 이를 꺼내오는 캐시 메커니즘
  ➡ RequestCache 내부의 SavedRequest 객체 - 사용자가 요청했던 request 속성, 헤더들을 저장.
  
  
• AccessDeniedException
  인가에 관련된 예외를 처리한다.
  특별한 동작은 없고 AccessDeniedHandler 에서 예외처리를 하도록 제공한다.

참고로 '익명사용자' 도 인증개체가 존재하기때문에, 인증예외가 아니라 인가예외가 발생한다.

RequestCache는 아래와 같이 사용할 수 있다.

protected void configure(HttpSecurity http) throws Exception {

    http.exceptionHandling() // 예외처리 핸들러 등록 (람다함수 사용)
        .authenticationEntryPoint(
            (request, response, authException) -> response.sendRedirect("/login"))
        .accessDeniedHandler(
            (request, response, accessDeniedException) -> response.sendRedirect("/denied"));

    
    http.formLogin()
        .successHandler((request, response, authentication) -> {
            RequestCache requestCache = new HttpSessionRequestCache();
            // 인증 예외가 발생하기 전 캐시된 Request 객체
            SavedRequest savedRequest = requestCache.getRequest(request, response);

            String redirectUrl = savedRequest.getRedirectUrl(); // 기존에 가고자 했던 URL
            response.sendRedirect(redirectUrl);
        });
}

RequestCacheFilter에서 이전의 Request 객체(savedRequest)를 세션에 캐싱하고 다음 필터로 넘긴다.

그리고 사용하는 시점에서 request.session에 있는 savedRequest를 꺼낸다.