일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
Tags
- 자바
- 코드스테이츠 백엔드 부트캠프 합격
- Spring
- 금감원 백내장 민원
- 금융감독원 민원신청
- HLB
- 코드스테이츠 합격
- 금융감독원
- Code States 백엔드 합격 후기
- 해시
- codestates 국비지원 1기 합격 후기
- Gamsgo
- 코드스테이츠 백엔드 후기
- 코드 스테이츠 백엔드 교육과정
- 코드스테이츠 백엔드 교육과정
- 겜스고
- 코테 합격후기
- 메서드
- 백내장 금감원
- 금감원
- 코드스테이츠 부트캠프
- CodeState 후기
- 백내장
- 코드스테이츠 부트캠프 합격 후기
- Java
- 코드스테이츠 합격 후기
- 보험금 지급거절
- 에이치엘비
- 백준 알고리즘
- 백내장 다초점렌즈 삽입술
Archives
- Today
- Total
개발하는 동그리
[인증\보안] Spring Security 기본 (인증/ 인가) 본문
반응형
Spring Security
- Spring Framework 기반의 애플리케이션 인증과 인가기능을 가진 프레임 워크
- 스프링 기반 애플리케이션의 표준 보안
- 스프링 인터셉터, 필터 기반 보안기능보다 더 권장됨
- 웹 애플리케이션에서 많이 쓰임
주체 (Principal)
- 사용자
인증(Authentication)
- 특정 리소스에 접급하려는 사용자 확인
- 주체의 신원 증명 과정
- 주체는 신원 증명 정보를 제시하고, 이는 보통 패스워드임
인가(Authorization)
- 인증을 마친 유저에게 권한을 부여해서 특정 리소스에 접근을 허가
- 인증과정 이후 수행되고, 권한은 롤 형태로 부여되는것이 일반적
접근 통제 (Access control)
- 어떤 유저의 리소스 접근 허가를 제어하는 행위
- 접근 통제 결정(Access control decision)이 뒤따름
- 리소스의 접근 속성과 유저에게 부여된 권한 또는 다른 속성들을 결정
Spring Security의 특징
- 모든 요청에 인증을 요구
- 사용자 이름,암호를 가진 사용자가 양식 기반으로 인증할 수 있도록 허용
- 사용자의 로그아웃 허용
- CSRF(Cross-Site Request Forgery)공격 방지
- Session Fixsation(세션 고정 공격) 보호
- 보안 헤더 통합
- HSTS 강화
- X-Context-typeOptions
- 캐시 컨트롤(정적 리소스 캐싱)
- X-XSS-Protection XSS 보안
- 클릭 재킹을 방지하는 X-Frame 옵션 통함
- 사용자가 어떤것을 클릭하게 속이는 방법으로 비밀정보 또는 컴퓨터에 대한 제어를 획득
- Servlet API 제공
토큰
- 사용자가 정상적으로 로그인 시도를 했을 때 정상적인 사용자인지 체크
- 정상적인 사용자가 확인되면 토큰값을 넘겨준다.
- 다음 로그인시 혹은 특정 로그인시 헤더 어소라이제이션에 토큰값이 같이 들어온다.
- 이 헤더의 토큰값을 확인해서 비교한다.
Filter
- 클라이언트가 서버로 요청을 하면 Servlet Filter를 수행
- Filter를 거친 후 DispatcherServlet과 같은 Servlet 요청이 처리
- Spring Security는 주요 보안에 대한 처리를 여러가지 Filter로 처리하도록 구성
- 대표적으로 인증(Authentication)과 인가(Authorization)에 대한 처리를 Filter에서 수행
- 자동 설정 옵션을 사용하면 10개의 Spring Security filter가 자동 설정 됨
Filter Interface
- public void init(FilterConfig filterConfig) throws ServletException
- Filter를 Web Container내에 생성한 후 초기화 할 때 호출
- Default 설정되있으므로 따로 구현하지 않아도 문제 없음
- public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws java.io.IOException, ServletException ⭐⭐⭐
- chain을 따라 다음에 존재하는 필터로 이동
- 체인의 가장 마지막에는 클라이언트가 요청한 최종 자원 위치
- public void destroy()
- Filter가 Web Container에서 삭제될 때 호출
- Default 설정되있으므로 따로 구현하지 않아도 문제 없음
이 중에서 필터에 역할을 하는 Method는 doFilter() 메서드다. 서블릿 컨테이너는 사용자가 특정한 자원을 요청했을 때 그 자원 사이에 필터가 존재할 경우, 그 필터 객체의 doFilter 메소드를 호출하며, 바로 이 시점부터 필터가 작용한다.
DelegatingFilterProxy
- 서블릿 컨테이너는 자체 표준을 사용해서 Filter 등록 가능 //But 스프링이 정의 하는 Bean은 인식하지 못함
- DelegatingFilterProxy는 표준 서블릿 컨테이너 메커니즘으로 등록할 수 있고, 모든 처리를 filter로 구현한 스프링 빈으로 위임
- 스프링 프레임워크 기반의 웹 애플리케이션에서 서블릿 필터 라이프 사이클과 연계해 스프링 빈 의존성을 서블릿 필터에 바인딩하는데 사용합니다.
- 서블릿 필터가 끝나면 스프링 컨테이너로 넘어가서 시큐리티 처리를 한다.
- 서블릿 필터처리하고 등록된 유저의 Role이나 name 을 가져오려면, 스프링 컨테이너의 Bean을 사용해서 이용해야 하는데 서블렛 컨테이너 에서는 스프링컨테이너 에 가서 Bean 을 이용할 수 없으니, 이런 일을 할 수 있도록 DelegatingFilterProxy 로 이런 서블렛 컨테이너의 필터에서 하지 못하는 일들을 따로 처리하도록 하는 것
필터에서 거르는 역할은?
- 인증처리 권한 자원 이동 등 필터가 체인으로 연결되어 있다.
- 필터는 서블릿 컨테이너에 되어있기 때문에
- 스프링 시큐리티는 스프링 컨테이너에서 동작한다.
- 필터는 서블릿 컨테이너에서 수행되므로 스프링 빈 도입이 안된다.
- 필터체인은 여러개의 필터를 통해서 순서대로 실행할 수 있는 순서로 되어있다.
- 각 필터들 하는 역할
- 리다이렉트
- 다음으로 넘어가면 안되고 응답만 보낼때
- 또는 다음 필터로 서블릿 필터를 통해서
필터 서블릿과 스프링 시큐리티의 연결
- 딜리게이팅필터프록시사용
- 필터 중간에 딜리게이팅 필터 프록시를 만나서 스프링 시큐리티 필터를 사용할 수 있다.
- 딜리게이팅은 스프링빈에 등록된 필터를 가져오는 역할만 가지고 있음
- 필터 체인 프록시, ,딜리게이팅 필터 프록시에 위임받고 필터체인이 관리한다.
- Security 필터체인을 가져감
- 여러개의 필터가 적용되어 있기 때문에 가져오기만 해도 된다!! (자동 적용)
- username, password, 인증 담당 역할
- 이 두개를 통해서 인증처리하는 것
- 이 필터는 3가지의 역할을 하게 되는데
- username pasword 인증하고 토큰 발행
- 토큰을 가지고 Authentication 보내서 인증절차
- Authentication providerㅇ를 통해 인증받게 됨
- 성공하든 실패하든 SecurituContextHolder 가 생성된다.
- principal : 통행증
- Credentials : 통행 자격
- Authorities : 권한
- Securit콘텍스트홀더에는 인증정보를 가지고 있다.
Authority = 권한
Authentication구현체가 GrantedAuthority객체 리스트를 저장
- GrantedAuthority 객체는 principal에게 부여한 권한을 나타냄
- GrantedAuthority는 메서드가 1개만 있는 인터페이스다.
- [인증] AuthenticationManager가 Authentication 객체에 설정해준다. [인증]
- [인가] AccessDecisionManager가 해당 Authentication 객체에서 GrantedAuthority를 꺼내서 접근 권한 결정
- string으로 쉽게 GrantedAuthority 조회
- GrantedAuthority구현체와 SimpleGrantedAuthority를 제공
- 사용자가 지정한 String을 GrantedAuthority로 변환
- AuthenticationProvider는 Authentication 객체에 값을 채울 때 SimpleGrantedAuthority를 사용
- SimplerGrantedAuthority 클래스는 String형태의 사용자 권한에 해당하는 문자열을 GrantedAuthority로 반환
AccessDecisionManager
- AbstractSecurityInterceptor에서 호출되며 최종 접근 제어를 결정
- 3가지 메서드
- decide
- 권한 부여하기 위한 결정을 내리는 필요한 모든 정보를 메서드에 전달
- secureObject를 전달하면 실제 보안 객체를 실행할 때 인자를 검사할 수 있음
- supports(ConfigAttribute)
- 실행 시점에 AbstractSecurityInterceptor가 호출되며, AccessDecisionManager가 전달 된 ConfigAttribute의 처리 가능 여부를 결정
- supports(Class)
- 시큐리티 인터셉터 구현체가 호출하며 저장한 AccessDecisionManager에서 시큐리티 인터셉터가 제출할 보안 객체타입을 지원하는지 확인
- decide
https://supawer0728.github.io/2018/04/04/spring-filter-interceptor/
https://developer-ping9.tistory.com/237
https://gardeny.tistory.com/35
반응형
'IT 정보 > Spring' 카테고리의 다른 글
[Spring] application.yml 설정 (1) | 2022.08.18 |
---|---|
[Spring] build.gradle 설정 (0) | 2022.08.18 |
[인증/보안] JWT(Json Web Token) 인증 (8) | 2022.07.29 |
[JPA] 이론 정리 (3) | 2022.07.29 |
[인증/보안] OAuth2 (2) | 2022.07.29 |