Spring/👨‍💻 SpringSecurity

기존의 JWT Filter 는 그저 리스트의 형태로써 URL만 사용할수 있고 와일드카드또한 사용할수 없었다. 이는 생각보다 매우 불편하다. 이는 프로젝트가 커지면 커질수록 불편해지고 심지어 와일드카드를 사용할 수 없게 되어 이렇게 징그러운 코드가 발생하게 되는것이다. 하지만 이는 해결책이 있었다. 물론 와일드까지 사용할수 있는 것이다. OncePerRequestFilter의 shouldNotFilter 이 필터는 OncePerRequestFilter 내부에 존재하는 메서드이다. 이 메소드의 주 용도는 내가 원하는 URL을 그냥 통과하게 만드는 것인데 정확한 공식문서는 Can be overridden in subclasses for custom filtering control, returning true ..

세션의 단점을 보안하기 위해 나온 Token들은 굉장히 다양하다. 우선 기본적으로 토큰은 서버에 요청을 할 때 헤더에 토큰을 함께 보내도록 하면서 유효성 검사를 도와준다. 이러한 시스템에서는 더 이상 사용자의 인증 정보를 서버나 세션에 유지하지 않고 클라이언트 측에서 들어오는 요청만으로 작업을 처리한다. 즉, Stateless 성격을 띄고있다. 장점 무상태성 & 확장성 : 토큰은 클라이언트 측에 저장되기 때문에 서버는 완전히 Stateless 하며, 클라이언트와 서버의 연결고리가 없기 때문에 확장하기 매우 적합하다 여러 플랫폼 및 도메인 : 서버 기반 인증 시스템의 문제점 중 하나인 CORS 를 해결할 수 있다 토큰을 사용하면 어떤 디바이스, 어떤 도메인에서도 토큰의 유효성 검사를 진행한 후에 요청을 처..

시큐리티를 접하면 가장 많이 공부하게 되는 필터이고 모르고 넘어갈래야 넘어갈수가 없는 필터로 왔다 이번에는 해당 필터에 대해서 배워보자 우선 가볍게 정말 당연하지만 우리가 로그인 하는 방식을 알아보자 사용자는 로그인을 먼저 하는것이 아니다! 우리의 전제 조건은 항상 인증이 필요한 요청을 한 사용자의 입장에서 먼저 시작한다 그렇다면 시큐리티는 사용자의 인증을 확인한다. 우리는 인증이 되지 않은 사용자를 기준으로 공부해볼것이기 때문에 인증이 안된 사용자로 시큐리티는 인식한다. 그럼 우린 인증이 안된 사용자에게 로그인 창을 권유하게 되는것이다. 그럼 로그인창으로 사용자는 formdata에 username과 password가 담신 post형태의 데이터를 넘긴다. 그럼 서버는 해당 사용자를 확인하고 session..

ExceptionTranslationFilter (인증과 인가의 예외 처리) AuthenticationException 인증 예외 처리 AuthenticationEntryPoint 호출 로그인 페이지로 이동하고, 401 오류 코드를 전달한다. 인증 예외가 발생하기 전의 요청 정보를 저장한다 RequestCache - 사용자의 이전 요청 정보를 세션에 저장하고 이를 꺼내 오는 캐시 메커니즘 SaveRequest - 사용자가 요청했던 request 파라미터 값들, 그 당시의 헤더값들 등이 저장되어있다. AccessDeniedException 인가 예외 처리 AccessDeniedHandler 에서 예외를 처리한다. 이 두가지의 예외를 누가? 누가 담당하고 발생시키는 것일까? 그 필터는 바로 FilterSec..

권한 설정이 무엇일까? 바로 우리가 시큐리티를 하게 되면 가장 고민하고 설정을 깔끔하게 해야할 부분이다 권한 설정은 방식이 설정되어 있는데 이는 두가지로 나뉜다. 선언적 방식 URL 을 통한 선언적 방식 http.requestMatcher("/user/**").hasRole("USER") Method 를 통한 선언적 방식 @PreAuthorize("hasRole('USER')") public void user() { System.out.println("user") } 동적 방식 - DB 연동 프로그래밍 URL Method 이런식으로 나뉜다. 각 페이지는 사용할수 있는 권한들이 있고 이는 사용자가 설정해주어야 한다. 그러면 훨씬 많은 페이지를 보다 간편하게 다룰수 있는것이다. 코드를 보면 이런식으로 설정이..

Anonymous 라는 이름 굉장히 친숙하다. 익명의 사용자를 뜻하는 Anonymous 를 처리하는 Filter가 있다니 굉장히 놀랍다 익명의 사용자 인증 처리 역시나 생각보다 굉장히 간단한 로직을 타고 있다. 하지만 여긴 중요한 것이 있기 때문에 꼭 알아두어야 할것이다 익명 사용자 인증 처리 필터 익명 사용자와 인증 사용자를 구분 화면에서 인증 여부를 구현할 때 isAnonymuos() 와 isAuthenticated() 로 구분해서 사용한다. 인증객체를 세션에 저장하지는 않는다. 우리는 상식적으로 인증을 할 때 과정은 유저가 인증을 하면 세션에 인증된 user객체를 저장하고 해당 사용자가 어딘가에 접근하려고 한다면 해당 세션에서 저장한 객체를 확인해서 이 객체가 null 인지 아닌지 확인해 인증을 판..

굉장히 흥미로운 필터이다. 기능으로 설명해보자면 우리가 로그인을 할때 로그인유지하기 라는 칸을 본적이 있을것이다. 여기서 사용하는 능력이라고 볼수 있다. 그리고 우리가 어떤 페이지를 들어갈때 오늘 하루 해당 광고 보지 않기 라는 말을 본적이 있을것이다. 그것또한 이것과 비슷하다 세션이 만료되고 웹 브라우저가 종료된 후에도 어플리케이션이 사용자를 기억하는 기능이다. Remember-Me 쿠키에 대한 Http 요청을 확인한 후 토큰 기반 인증을 사용하여 유효성을 검사하고 토큰이 검증되면 사용자는 로그인 된다. 사용자의 라이프 사이클 인증 성공(Remember-Me 쿠키 설정) 인증 실패(쿠키가 존재한다면 쿠키 무효화) 로그 아웃(쿠키가 존재한다면 쿠키 무효화) 코드를 작성하는 요령은 이러하다. remembe..

두가지의 순서는 생각보다 많은 차이가 있다. 하지만 서로 굉장히 밀접한 관계가 있기 때문에 동시에 설명하려고 한다. CuncurrentSessionFilter 매 요청마다 현재 사용자의 세션 만료 여부 체크 세션이 만료되었을 경우 즉시 만료 처리 이러한 행위를 담당하는것이 CuncurrentSessionFilter 이다. 해당 세션이 만료가 되었는지 확인하고 만료가 되었다면 오류페이지를 응답시킴으로써 필터를 통과하지 못한다. 간단한 필터이기 때문에 이해는 어렵지 않지만 중요한것은 SessionManagementFilter와 연관이 되어있다는것이다. 어떻게 연관이 되어있는걸까 SessionManagementFilter 가 하는 과정에서 중요한 작업이 있다. 이글을 그냥 보고있는 독자는 SessionMana..

시큐리티에서의 세션은 굉장히 중요한 역할을 한다. 클라이언트와의 연결 관계에서도 아주 큰 역할을 하고 우리 서비스의 사용자와의 얘기에도 엄청나게 큰 역할을 한다. 그렇다면 세션이라는것은 시큐리티에서 가장 신경을 많이 쓰고 까다롭게 생성하고 사용되어야 한다는 말이다. 그렇다면 시큐리티의 세션을 담당하는 필터는 무엇이며 해당 필터는 어떤 일을 하는지 알아보자 SessionManagementFilter 세션 관리 당연하게도 인증시 사용자의 세션 정보를 등록하고 조회, 삭제등의 다양한 세션의 이력을 관리한다. 동시적 세션 제어 동일 계정으로 접속이 허용되는 최대 세션수를 제한한다 세션 고정 보호 인증 할 때마다 세션 쿠키를 새로 발급하여 공격자의 쿠키 조작을 방지한다 세션 생성 정책 Always, If_Requ..

시큐리티는 로그아웃을 했을때 적용하는 필터도 있다. 해당 필터의 내용은 간단하다. 너무 간단하니 말로 설명해보자면 클라이언트는 로그아웃이라는 요청을 보낸다. 그럼 서버에서는 해당 요청을 처리하게 되고 서버는 로그아웃에 대한 처리를 한다 대표적으로는 세션 무효화, 인증 토큰 삭제, 쿠키 정보 삭제를 시키고 로그인 페이지를 리다이렉트로 넘기기도 한다. 여기서 인증 토큰을 삭제 한다는 것은 우리가 SecurityContext 에 넣어놓았던 인증 객체를 말한다. 그럼 진행 순서를 한번 알아보자 사용자가 로그아웃 요청을 하면 LogoutFilter 에서 이 요청을 지나간다. 그럼 AntPathRequestMatcher가 해당 요청의 URL을 확인하고 맞다면 filter의 작업을 시작한다. 그럼 Context안에 ..