Spring Security

SecurityFilterChain

전체적인 스프링 시큐리티 흐름

1. Http Request 수신

• 사용자가 로그인 정보와 함께 인증 요청을 한다.

2. AuthenticationFilter가 요청을 가로채고, 가로챈 정보로 UsernamePasswordAuthenticationToken의 인증 용 객체를 생성한다.
3. AuthenticationManager의 구현체인 ProviderManger에게 앞서 생성한 UsernamePasswordToken 객체를 전달한다.
4. AuthenticationManager는 등록된 AuthenticationProvider 리스트 중에서 처리할 수 있는 provider에게 인증 처리를 위임한다.
5. 앞서 선택된 AuthenticationProvider가 등록된 UserDetailsService(직접 구현 가능)에게 사용자 정보를 넘겨주게 된다.
6. UserDetailsService는 넘겨 받은 사용자 정보를 통해 DB에서 사용자 정보를 찾게되고, 찾은 정보로 UserDetails 객체를 만들어 넘겨준다.(UserDetails 직접 구현 가능)
7. AuthenticationProvider 들은 UserDetails를 넘겨 받고, UsernamePasswordAuthenticationToken의 사용자 정보와 비교한다.
8. 인증이 완료되면 AuthenticationManager(ProviderManager)가 사용자 정보와 권한 등을 포함하고 있는 Authentication 객체를 생성하여 반환해준다.
9. AuthenticationFilter에 Authentication객체가 반환 되어진다.
10. SecurityContext의 영역에 Authentication객체를 저장한다.

• 즉, 10번까지 처리가 완료되었다면 SecurityContextHolder는 세션 영역에 있는 SecurityContext에 Authentication 객체를 저장하게 되는 것이다.

---

**PICKME에 스프링 시큐리티 적용하기 ~ **

WebSecurityConfig.java 설명

	@Bean
	public WebSecurityCustomizer webSecurityCustomizer() {
		return (web) -> web.ignoring()
			.requestMatchers(
				PathRequest.toStaticResources().atCommonLocations()
			);
	}

• 이부분은 css, js, 이미지 등 **정적 리소스**에 대한 보안을 적용하지 않기 위해 설정한 부분

---

	@Bean
	public SecurityFilterChain userfilterChain(HttpSecurity http) throws Exception {
		AuthenticationManagerBuilder managerBuilder = http.getSharedObject(AuthenticationManagerBuilder.class);
		configureAuthenticationManager(managerBuilder, userDetailService);

		return commonSecurityFilter(http, "/user/**", "/user/loginForm", "/user/login", "/user/loginForm?error=true");
	}

	@Bean
	public SecurityFilterChain adminfilterChain(HttpSecurity http) throws Exception {
		AuthenticationManagerBuilder managerBuilder = http.getSharedObject(AuthenticationManagerBuilder.class);
		configureAuthenticationManager(managerBuilder, customosDetailService);

		return commonSecurityFilter(http, "/customs/**", "/customs/loginForm", "/customs/login", "/customs/loginForm?error=true");
	}

현재 우리 프로젝트에서는 관리자(Customs)와 사용자(User)가 따로 있기 때문에

각각의 보안 설정을 별도로 구성하고 했다.

• SecurityFilterChain을 빈으로 등록하여, 요청 경로별로 각각 다른 보안 설정을 적용한다.
• userFilterChain
  • /user/** 경로에 대한 보안 설정 적용
  • 사용자 인증을 위해 userDetailService를 설정
• adminFilterChain()
  • /customs/** 경로에 대한 보안 설정 적용
  • 관리자 인증을 위해 customosDetailService를 설정

---

	private void configureAuthenticationManager(AuthenticationManagerBuilder managerBuilder, UserDetailsService userDetailsService) throws Exception {
		managerBuilder.userDetailsService(userDetailsService)
			.passwordEncoder(bCryptPasswordEncoder());
	}

• 공통 보안 설정 메서드
• 주어진 UserDetailService와 BcryptPasswordEncoder를 사용하여 인증 관리자(AuthenticationManager)를 구성

---

	private SecurityFilterChain commonSecurityFilter(HttpSecurity http, String securityMatcher, String loginPage, String loginProcessingUrl, String failureRedirectUrl) throws Exception {
		http
			.securityMatcher(securityMatcher)
			.formLogin(AbstractHttpConfigurer::disable)
			.cors(AbstractHttpConfigurer::disable)
			.csrf(AbstractHttpConfigurer::disable)
			.authorizeHttpRequests((authorize) -> authorize
				.requestMatchers(securityMatcher).permitAll()
				.anyRequest().authenticated())
			.formLogin(form -> form
				.loginPage(loginPage)
				.usernameParameter("id")
				.loginProcessingUrl(loginProcessingUrl)
				.successHandler(authenticationSuccessHandler())
				.failureHandler((request, response, exception) -> {
					response.sendRedirect(failureRedirectUrl);
				}).permitAll()
			)
			.sessionManagement(sessionManagementConfigurer ->
				sessionManagementConfigurer.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
					.sessionFixation(SessionManagementConfigurer.SessionFixationConfigurer::changeSessionId)
					.maximumSessions(1)
					.maxSessionsPreventsLogin(true)
					.expiredUrl(loginPage));

		return http.build();
	}

• 로그인 페이지, 로그인 처리, URL 처리, 성공/실패 핸들러 등을 설정
• authenticationSuccessHandler() 인증 성공 핸들러를 구현하여 인증에 성공한 사용자의 권한에 따라 redirect 할 성공 화면을 다르게 구현함(정확한 구현은 코드 참고!)

여기까지 전체적인 흐름은

1. 사용자가 /user/loginForm URL로 GET 요청을 보낸다.
   • Spring Security는 이 요청을 받아 처리한다.
2. SecufityFilterChain 탐색
   • Spring Security는 요청 URL이 /user/** 패턴과 일치하는지 확인한다.
   • 이 패턴은 userFilterChain(HttpSecurity http) 메서드에서 설정된 SecurityFilterChain에 의해 처리된다.
3. Form Login 설정 확인
   • userFilterChain 메서드의 commonSecuiryFilter 메서드에서 formLogin() 설정을 확인해서 설정된 loginPage인 /user/loginForm으로 페이지를 이동
4. 로그인 폼 제공
   • /user/loginForm 요청이 들어오면 스프링 시큐리티는 이 요청을 처리하여 로그인 페이지를 반환한다.
   • 사용자로부터 username, password를 입력받는 역할을 한다.
5. 로그인 페이지 작동
   • 사용자는 id 와 password를 입력하고, 로그인 버튼을 클릭하여 폼을 제출
   • 이때 loginProcessingUrl로 지정된 /user/login 으로 POST 요청을 보낸다.
6. 로그인 인증 처리
   • /user/login 요청이 들어오면, Spring Security는 사용자가 입력한 id와 password를 userDetailService를 통해 검증한다.
   • userDetailService는 데이터베이스에서 사용자의 정보를 가져와서 입력된 비밀번호가 맞는지 확인한다.
7. 인증 성공/실패 처리
   • 만약 인증이 성공하면 위에서 설정한 .successHandler(authenticationSuccessHandler()) 에 설정한 대로 실행된다
   • 실패한 경우 .failureHandler 설정한 대로 실행된다.

이후의 과정은 위에서 시큐리티 흐름의 8번 이후 과정이 진행된다.

8번 이후에 생성된 Authenticaition 객체를 통해서 @CurrentUser 어노테이션을 구현하여 로그인 된 사용자의 정보를 가져올 수 있다!(이 부분은 다른 곳에 정리)

---

Spring Security 세션 관리

			.sessionManagement(sessionManagementConfigurer ->
				sessionManagementConfigurer.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
					.sessionFixation(SessionManagementConfigurer.SessionFixationConfigurer::changeSessionId)
					.maximumSessions(1) //한 유저가 가질 수 있는 최대 세션 개수
					.maxSessionsPreventsLogin(true)
					.expiredUrl("/user/loginForm"));

• maximumSession(1): 최대 허용 가능 세션 수를 설정
  • -1로 넣으면 무제한 세션 생성 허용
• maxSessionPreventsLogin(true): 위에서 설정한 최대 허용 세션의 수가 되었을 때 추가적인 인증이 있을 경우 어떻게 처리할지 설정
  • true면 현재 사용자 인증 실패, false(default)면 기존 세션 만료
• expiredUrl(”/user/loginForm”): 세션이 만료된 경우 이동 할 페이지를 설정

maximumSession(1) 최대 세션 개수일 때 처리 방법

1. 이전 사용자 세션 만료

• 사용자 1이 로그인을 하면 서버에 해당 계정에 대한 세션이 생성된다.
• 사용자 2가 사용자1과 동일 계정으로 로그인을 시도하게 되면 여러 filter 중 SessionManageMentFilter에서 maximumSession()의 값이 1인 것을 확인한다.
• 서버는 새롭게 접근을 시도한 사용자 2의 세션을 새로 생성하고 인증을 해주며 사용자 1의세션은 session.isExpired() == true로 변경하여 세션 마료 설정을 해준다.
• 사용자 1이 다시 request를 요청하면 ConcurrentSessionFilter에서 session.isExpired()값을 확인하여 세션 만료여부를 확인 후 새로운 세션을 만들도록 인증 요청을 하게 된다.

2. 새로운 사용자 인증 실패

• 사용자 1이 로그인을 하면 서버에 해당 계정에 대한 세션이 생성된다.
• 사용자 2가 사용자1과 동일 계정으로 로그인을 시도하게 되면 여러 filter 중 SessionManageMentFilter에서 maximumSession()의 값이 1인 것을 확인한다.
• 서버에서는 사용자 2의 세션을 생성되지 않고 인증 예외를 발생시킨다.

💡**세션 관련 필터

ConcurrentSessionFilter**

• 매 요청마다 사용자의 세션의 session.isExpired() 여부를 확인하여 세션이 만료 되었을 경우 로그아웃처리(만료 처리)를 해주는 필터

SessionManageMentFilter

• 동시적 세션 제어, 세션 고정 보호, 세션 생성 정책 등의 세션의 전반적인 관리를 해주는 필터

세션 고정 보호

        http.sessionManagement()
                .sessionFixation().changeSessionId()

• changeSesseionId(): 사용자가 인증을 시도하게 되면 사용자 세션은 그대로 두고 세션 아이디만 변경 한다
• migrateSession(): 새로운 세션을 생성하고 세션 아이디도 새로 발급하며 migration한다.(서블릿 3.1이전에서 기본 값)
• newSession(): 새로운 세션 아이디를 생성하며 이전의 설정 값들을 사용 불가
• none(): 아무런 보호X

chageSessionId(), migrateSession()은 이전 세션의 설정 값들을 그대로 사용할 수 있지만 newSession()의 경우 새로운 세션을 생성하여 이전 설정 값을 사용하지 못한다.

세션 정책 설정

 http.sessionManagement()
                .sessionCreationPolicy(SessionCreationPolicy.If_Required)

• SessionCreationPolicy.Always: 스프링 시큐리티가 항상 세션을 생성한다.
• SessionCreateionPolicy.If_Required: 스프링 시큐리티가 필요시 생성한다.(default)
• SessionCreateionPolicy.Never: 스프링 시큐리티가 생성하지 않지만 이미 존재하면 사용한다.
• SessionCreateionPolicy.Stateless: 스프링 시큐리티가 생성하지 않고 존재해도 사용하지 않는다.(JWT와 같이 세션을 사용하지 않는 경우 사용함)